Re: [patch net-next v2 8/9] switchdev: introduce Netlink API

[Thomas Graf <tgraf@suug.ch>]

On 09/22/14 at 08:10am, Tom Herbert wrote:
> Thomas, can you (or someone else) quantify what the host case is. I
> suppose there may be merit in using a switch on NIC for kernel bypass
> scenarios, but I'm still having a hard time understanding how this
> could be integrated into the host stack with benefits that outweigh

Personally my primary interest is on lxc and vm based workloads w/
end to end encryption, encap, distributed L3 and NAT, and policy
enforcement including service graphs which imply both east-west
and north-south traffic patterns on a host. The usual I guess ;-)

> complexity. The history of stateful offloads in NICs is not great, and
> encapsulation (stuffing a few bytes of header into a packet) is in
> itself not nearly an expensive enough operation to warrant offloading

No argument here. The direct benchmark comparisons I've measured showed
only around 2% improvement.

What makes stateful offload interesting to me is that the final
desintation of a packet is known at RX and can be redirected to a
queue or VF. This allows to build packet batches on shared pages
while preserving the securiy model.

Will the gains outweigh complexity? I hope so but I don't know for
sure. If you have insights, let me know. What I know for sure is that
I don't want to rely on a kernel bypass for the above.

> to the NIC. Personally, I wish if NIC vendors are going to focus on
> stateful offload I rather see it be for encryption which I believe
> currently does warrant offload at 40G and higher speeds.

Agreed. I would like to be see a focus on both.