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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Mar 2014 08:58:29 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Thomas Graf <tgraf@...g.ch>, Neil Horman <nhorman@...driver.com>
CC:	Jiri Pirko <jiri@...nulli.us>,
	Florian Fainelli <f.fainelli@...il.com>,
	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>, andy@...yhouse.net,
	dborkman@...hat.com, ogerlitz@...lanox.com, jesse@...ira.com,
	pshelar@...ira.com, azhou@...ira.com,
	Ben Hutchings <ben@...adent.org.uk>,
	Stephen Hemminger <stephen@...workplumber.org>,
	jeffrey.t.kirsher@...el.com, vyasevic <vyasevic@...hat.com>,
	Cong Wang <xiyou.wangcong@...il.com>,
	John Fastabend <john.r.fastabend@...el.com>,
	Eric Dumazet <edumazet@...gle.com>,
	Scott Feldman <sfeldma@...ulusnetworks.com>,
	Lennert Buytenhek <buytenh@...tstofly.org>
Subject: Re: [patch net-next RFC 0/4] introduce infrastructure for support
 of switch chip datapath

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