Re: Flows! Offload them.

[Jamal Hadi Salim <jhs@mojatatu.com>]

Hi John,

On 02/27/15 10:23, John Fastabend wrote:
> On 02/27/2015 05:33 AM, Jamal Hadi Salim wrote:


>> 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
>

For hardware, we are talking abstractions, no? i.e it doesnt have
to be 1-1 mapping. IOW, It shouldnt matter how the hardware table
looks like as long as the kernel abstractions work on it.
There are two hooks:
either ingress or egress. These can be expressed in the kernel via
policy. Most hardware supports either one or the other.
IOW, I think the expressability in software is sufficient. In the
h/ware you are referring to - it is ingress.

> 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.
>

I agree - this is an interesting exception from a policy expression
view.

> 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.
>

we do need the namespace separation. The concept of a "netdev" that
exists in hardware but is hidden at the hypervisor level is something
that needs to be addressed. I am still in love with concept of
abstracting these things as netdevs.
The question is how do you map which "vsi:" to which netdev on which
VM?

cheers,
jamal