[RFC net-next PATCH 3/4] ethtool: Add new set commands

Rose, Gregory V
Thu, 28 Jul 2011 22:04:22 -0000

> -----Original Message-----
> From: netdev-owner at vger.kernel.org [mailto:netdev-owner at
vger.kernel.org]
> On Behalf Of Anirban Chakraborty
> Sent: Thursday, July 28, 2011 3:01 PM
> To: Rose, Gregory V
> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T;
> virtualization at lists.linux-foundation.org
> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set commands
>
>
> On Jul 28, 2011, at 1:38 PM, Rose, Gregory V wrote:
>
> >
> >> From: Anirban Chakraborty [mailto:anirban.chakraborty at
qlogic.com]
> >> Sent: Thursday, July 28, 2011 12:04 PM
> >> To: Rose, Gregory V
> >> Cc: David Miller; netdev; Ben Hutchings; Kirsher, Jeffrey T
> >> Subject: Re: [RFC net-next PATCH 3/4] ethtool: Add new set
commands
> >>
> >>
> >> If I understood it correctly, you are trying to set/unset spoofing
on
> per
> >> eth interface,  which could be a PF on the hypervisor or a pci
> passthru-ed
> >> VF in the linux guest.  There are other security features that one
> could set
> >> for a port on the VF (lets call it vport),  e.g. setting a port
VLAN ID
> for
> >> a VF and specifying if the VF (VM) is allowed to send
tagged/untagged
> >> packets, setting a vport in port mirroring mode so that the PF can
> monitor
> >> the traffic on a VF,  setting a vport in promiscuous mode etc.
> >>
> >> Does it make sense to try to use ip link util to specify all these
> parameters,
> >> since ip link already does the  job of setting VF properties and
VF
> port
> >> profile?
> >>
> >> Any thoughts?
> >>
> >
> > Sure, that's a possibility too.  I was considering ethtool for
this
> since MAC addresses and VLANs are fairly specific to Ethernet whereas
> netlink might apply to other types of physical networks.  At least
that's
> my understanding.
>
> You could specify VF MAC and VLANs using netlink today.
> e.g. ip link set ethX vf # mac, vlan etc.
> Adding spoofing as follows would do it.
> ip link set ethX vf # spoof on|off
>
> Having SR-IOV features scattered among ethtool and ip link may be
> inconvenient for the end users.
> CC-ing virtualization list.
>
> >
> > However, I have no strong feelings about it and if community consensus
> is to use ip link instead then that's fine by me.
> >
> > Of course, patches implementing such would be quite welcome also.
>
> I could take a stab at it at the netlink side, if there is a consensus.

Now that I think about it I'm seeing it more your way.  I'll drop the
anti-spoofing stuff from my ethtool patches.  If you get the time to provide
patches to netlink for anti-spoofing then that's great, otherwise I'll
do it when I get done with the SR-IOV reconfig stuff.

Thanks,

- Greg