On 03/26/14 07:29, Thomas Graf wrote:

On 03/26/14 at 07:10am, Neil Horman wrote:

quoted

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