Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support of switch chip datapath

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 26 Mar 2014 08:58:29 -0400

On 03/26/14 07:29, Thomas Graf wrote:
> On 03/26/14 at 07:10am, Neil Horman wrote:
>> But by creating net_devices that are registered in the current fashion we
>> implicitly agree to levels of functionality that are assumed to be available and
>> as such are not within the purview of a net_device to reject.  E.g. it is
>> assumed that a netdevice can filter frames using iptables/ebtables, limit
>> traffic using tc, etc.
>
> I think this is the point where we disagree. We already have several
> devices that hook into the rx handler and never have their packets
> pass through either iptables or ebtables. Better examples of this are
> macvtap or OVS.
>

I am going to disagree here.
Where it makes sense to use port handling is when you have port
layering.
Really dont need to create another parallel stack just because this
is to reflect what is in the hardware. There are corner cases, but
not the ones discussed.
Use ebtables if that is what the hardware reflects best.
Use tc when that is the better abstraction (example: for years now I
have modelled the broadcom acls with tc classifier/actions just fine).

> What should happen is that these devices are given a chance to implement
> the ACL in their own flow table. If no such facility exists, the rule
> insertion should fall back to software mode if that is possible (an
> OF capable switching chip could insert a 'upcall' flow), or as
> a last resort return an error to indicate EOPNOTSUPP.
>

I would like to specify where the acl rule goes.
Refer to the bridge port fdb offloading as an example.

cheers,
jamal