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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 27 Mar 2014 18:26:00 +0100
From:	Jiri Pirko <>
To:	Thomas Graf <>
Cc:	Florian Fainelli <>,
	Jamal Hadi Salim <>,
	netdev <>,
	David Miller <>,
	Neil Horman <>,
	Andy Gospodarek <>,
	dborkman <>, ogerlitz <>,
	jesse <>, pshelar <>,
	azhou <>, Ben Hutchings <>,
	Stephen Hemminger <>,, vyasevic <>,
	Cong Wang <>,
	John Fastabend <>,
	Eric Dumazet <>,
	Scott Feldman <>,
	Roopa Prabhu <>,
	John Linville <>,
	dev <>
Subject: Re: [patch net-next RFC v2 0/6] introduce infrastructure for support
 of switch chip datapath

Thu, Mar 27, 2014 at 06:20:48PM CET, wrote:
>On 03/27/14 at 09:27am, Florian Fainelli wrote:
>> 2014-03-27 4:02 GMT-07:00 Thomas Graf <>:
>> > There is definitely need beyond an ndo that is capable of
>> > adding flows. You mention routes. Another example would be
>> > devices capable of offloading iptables & nft rules.
>> Those devices usually require (at least for Broadcom) an entity
>> identifying the flows and uploading flows offloading rules to the
>> hardware. Although I do not think it hurts to keep those in mind to
>> come up with the right design, my feeling is that they will require
>> more intrusive modifications at the socket, route and forwarding path
>> level if we want the Linux kernel to offer a consistent API across
>> different hardware variations.
>I absolutely agree. This is where the challenging bits start to
>appear ;-) I don't want to speak for Jiri but my understanding is
>that the flow focused approach early on is entirely because it is
>the easiest case to solve. Taking OVS as an example has the
>advantage of already being guarded by OpenFlow abstraction which
>by nature is very device oriented.

Yep, exactly.

>> It is not clear to me at this point whether we want those special
>> offloading devices to appear as separate net_device with specific
>> flags to advertise their offloading features (NAT, IP routing...) or
>> something else?
>One lesson that could serve as an example which differs from TOE is
>the offloading provided by recent FC HBAs. The device looks like a
>regular SCSI device to the kernel but offers a full DCB engine to
>allow for FCoE. The DCB bits can and must be configured. By not
>representing that engine with a net_device we cannot configure the
>engine through the Netlink interface dcbnl. dcbnl can certainly be
>extended to allow taking a scsi id of some sort instead of a ifindex
>but it's far from ideal.
>My take on this is that if it makes sense to use rtnl or ethtool
>to configure these offload engines then let's just go with a
>globally visible net_device and improve our capabilities system.
>> > But wouldn't you want to introduce an additional ndo to
>> > cover these?
>> I would start with making sure everyone is on the same page regarding
>> switches before we start building the conversation on NAT/IP-routing
>> offloading, but it is good that you mention it.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists