[Intel-wired-lan] [next PATCH 1/5] i40e: Introduce devlink interface.

[John Fastabend <john.fastabend@gmail.com>]

On 16-08-16 05:17 PM, Alexander Duyck wrote:
> On Tue, Aug 16, 2016 at 2:51 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>> The idea behind NTUPLE filters on VF representors is to match RX traffic
>> that is destined
>> for the corresponding VF. Basically when adding the flow director filter, we
>> are setting the
>> dest vsi as the VSI of the corresponding VF.
>> Without VF representors, this is currently done by overloading user-def
>> value with VF id.
>>
> 
> Yes, and for now that is preferable to what you are doing since it
> makes no sense.
> 
> I will try to clarify my point.  First, instead of calling these VF
> representors lets call them VF port representor, or VFPR for short
> (trying to avoid VFR because it sounds too much like VRF which is
> completely unrelated).  So the whole point of a VFPR is to present the
> VF as a port on your logical switch.  You should mostly only be
> capable of doing on it what you would do with an actual switch.  So
> for example if I have a switch connected to NIC.  Now most switches
> have certain options for controlling things.  For example I can force
> the switch port onto a given VLAN so that the port is isolated from
> other traffic.  I can control the max frame size allowed to be sent or
> received over the port.  I can block what traffic the port is allowed
> to send by restricting MAC addresses via ACLs, and I can manually
> program the forwarding table via FDB entries.
> 
> The problem is Flow Director also know as NTUPLE or Rx NFC only
> operates on the Rx side of NICs.  In your VFPR the Rx side represents
> packets coming from your VF, not packets going to it.   If you
> transmit on a VFPR the packet should be received only by the VF, if
> you receive from it the packet should only be from the VF.  So really
> any Flow Director rule you add to the VFPR should not impact the VF,
> but instead should impact the VFPR and the PF since the PF will add
> the rule and it should only apply on traffic received on the VFPR from
> the VF.
> 
> At some point in the future we can look at adding flow Tx offloads via
> either TC or SwitchDev.  For now adding NTUPLE is a strong no-go.  The
> VFPR are not the place to do it unless you are just wanting to add
> custom rules to the PF itself that won't impact the VF.
> 
> - Alex
> 

FWIW the features I want from the VFPR (nice acronym :) are the
following,

  - xmit (just send it over the PF queues is fine)
  - recv : ideally the driver does this with descriptor magic but
           the next best thing would be to do this in the driver
	   with a lookup on mac when anti-spoofing is on. Or worst
           case if the driver logic is too ugly I'll hack it in
           userspace :(
  - up/down link state
  - statistics
  - not essential but mtu would also be nice

I think thats it to get my basic stuff working in userspace. Another
nice piece would be the fdb_add offloads so we can get a basic l2 bridge
working and bonus points for including the vlan parts of the fdb_add
msg.

Thanks,
John