Hi John,

On 02/27/15 10:23, John Fastabend wrote:

On 02/27/2015 05:33 AM, Jamal Hadi Salim wrote:

quoted

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