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