On Mon, Sep 22, 2014 at 3:17 PM, Thomas Graf <tg...@suug.ch> wrote: > 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. > How is this different from what rx-filtering already does?
> 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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
