Re: Flows! Offload them.

[John Fastabend <john.r.fastabend@intel.com>]

On 02/27/2015 05:33 AM, Jamal Hadi Salim wrote:
> On 02/26/15 10:39, John Fastabend wrote:
> 
>> So I think there is a relatively simple solution for this. Assuming
>> I read the description correctly namely packet ingress' nic/switch
>> and you want it to land in a namespace.
>>
>> Today we support offloaded macvlan's and SR-IOV. What I would expect
>> is user creates a set of macvlan's that are "offloaded" this just means
>> they are bound to a set of hardware queues and do not go through the
>> normal receive path. Then assigning these to a namespace is the same
>> as any other netdev.
>>
>> Hardware has an action to forward to "VSI" (virtual station interface)
>> which matches on a packet and forwards it to either a VF or set of
>> queues bound to a macvlan. Or you can do the forwarding using standards
>> based protocols such as EVB (edge virtual bridging).
>>
>> So its a simple set of steps with the flow api,
>>
>>     1. create macvlan with dfwd_offload set
>>     2. push netdev into namespace
>>     3. add flow rule to match traffic and send to VSI
>>         ./flow -i ethx set_rule match xyz action fwd_vsi 3
>>
>> The VSI# is reported by ip link today its a bit clumsy so that interface
>> could be cleaned up.
>>
>> Here is a case where trying to map this onto a 'tc' action in software
>> is a bit awkward and you convoluted what is really a simple operation.
>> Anyways this is not really an "offload" in the sense that your taking
>> something that used to run in software and moving it 1:1 into hardware.
>> Adding SR-IOV/VMDQ support requries new constructs. By the way if you
>> don't like my "flow" tool and you want to move it onto "tc" that could
>> be done as well but the steps are the same.
>>
> 
> Sorry for the top post - just wanted to leave the context intact.
> TU (that is a "thumbs up" from an anti +1 person) on what you said
> above. But i dont see the issue you bring up in step #3. If i was to
> say:
> 
> tc filter add ingress ethx classifier foo priority X \
> match xyz action redirect macvlan3 offload
> 
> where "offload" sets the netlink or classifier specific instruction
> to offload.
> 
> You can easily map macvlan3 to vsi 3.
> 

This is why I said if you want to map my "flow" tool onto "tc" it can
be done. :) I made a jump from macvlans that have net device representations
to VFs being assigned to user space (VMs) where there is no net device
to "redirect" to. So my explanation wasn't clear. Couple additional notes,

The only issue I have with your 'tc' case is the "ingress" qdisc is per port where
my flow tool is scoped at the switch pipeline so I would modify your cmd
slightly and use a new classifier hook,

 tc filter add sw-pipeline ethx classifier flow priority X \
    match xyz action redirect macvlan3 offload

The other thing to note is "redirect" to macvlan3 doesn't handle the case
where the VF is direct assigned to a VM in this case we don't have a netdev
in the hypervisor to "redirect" to. Using the VSI# allows the hardware
to translate the redirect cmd to the VF.

So one more slight tweak,

 tc filter add sw-pipeline ethx classifier flow priority X \
    match xyz action redirect vsi:2 offload

use the "vsi:" prefix to indicate this is for a hardware mapped VSI this
way the user can use what ever notion is more convenient.

> cheers,
> jamal
> 
> 
>