Thu, Mar 27, 2014 at 06:20:48PM CET, tg...@suug.ch wrote: >On 03/27/14 at 09:27am, Florian Fainelli wrote: >> 2014-03-27 4:02 GMT-07:00 Thomas Graf <tg...@suug.ch>: >> > 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. > >Agreed _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
