Date:	Mon, 02 Mar 2015 08:45:21 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	John Fastabend <john.r.fastabend@...el.com>,
	Shrijeet Mukherjee <shrijeet@...il.com>,
	Thomas Graf <tgraf@...g.ch>
CC:	Jiri Pirko <jiri@...nulli.us>,
	Simon Horman <simon.horman@...ronome.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"nhorman@...driver.com" <nhorman@...driver.com>,
	"andy@...yhouse.net" <andy@...yhouse.net>,
	"dborkman@...hat.com" <dborkman@...hat.com>,
	"ogerlitz@...lanox.com" <ogerlitz@...lanox.com>,
	"jesse@...ira.com" <jesse@...ira.com>,
	"jpettit@...ira.com" <jpettit@...ira.com>,
	"joestringer@...ira.com" <joestringer@...ira.com>,
	"sfeldma@...il.com" <sfeldma@...il.com>,
	"f.fainelli@...il.com" <f.fainelli@...il.com>,
	"roopa@...ulusnetworks.com" <roopa@...ulusnetworks.com>,
	"linville@...driver.com" <linville@...driver.com>,
	"gospo@...ulusnetworks.com" <gospo@...ulusnetworks.com>,
	"bcrl@...ck.org" <bcrl@...ck.org>
Subject: Re: Flows! Offload them.

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



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists