Well, things such as IPSec offload, and more obscure stuff such as: "any media-specific out-of-band data that accompanies the NET_BUFFER structures that are associated with the NET_BUFFER_LIST structure."
The complete list, which includes the latest version of NDIS, is here: http://msdn.microsoft.com/en-us/library/windows/hardware/ff566569(v=vs.85).aspx Obviously, other things would be added in the future. What happens if you remove IPSec for a packet? What happens if you remove contextual information written by some network driver in the stack that are required by another network driver in the stack? Well, perhaps it won't bring the system down, but it would still not be a good thing to do. I believe it is not a good idea to leave it to "whatever may go wrong with the packet". Sam ________________________________________ From: Ben Pfaff [b...@nicira.com] Sent: Sunday, August 03, 2014 8:10 PM To: Samuel Ghinet Cc: dev@openvswitch.org Subject: Re: [ovs-dev] Queuing packets to userspace and NBL info problem On Sun, Aug 03, 2014 at 05:06:14PM +0000, Samuel Ghinet wrote: > I think this is a problem that both implementations suffer of: Namely, > when we give a packet to the userspace, we strip off the NBL info > array from it. In other words, when the packet gets back from the > userspace and must be outputted to ports, all NBL info that it had > before is cleared out. > > We can handle manually NBL info such as checksum offload or LSO. But > normally, all other NBL info in the array are important, and we cannot > simply strip them away. On Linux, the "sk_buff" kernel data structure used for packets has tons of extra info that gets stripped when the packet goes to userspace. It doesn't cause a problem. What is different the Windows NBL? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
