Yes. In addition, some packets may get sent to an OpenFlow controller.
On Sun, Aug 03, 2014 at 06:52:55PM +0000, Eitan Eliahu wrote: > > Hi Samuel, my initial implementation was holding a reference to NBLs > which were indicated to user mode. However, there is an issue with > that as in general not all packets are returned to back to the kernel > and some packets could be modified in user space. Perhaps, Ben could > confirm? Thanks, Eitan > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Samuel Ghinet > Sent: Sunday, August 03, 2014 10:06 AM > To: dev@openvswitch.org > Subject: [ovs-dev] Queuing packets to userspace and NBL info problem > > Hello guys, > > 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. > > I am thinking of alternatives to the current approach: > a) keep the queue of NBLs in the driver only, and give to the userspace the > keys instead. (this would be most preferable for the kernel part) AFAIK, in > the current implementation, only the metadata is sent as keys in an upcall. > > b) if it is too much to change in userspace for approach a), perhaps we can > keep the queue of NBLs in the driver, and send as "buffer to userspace" only > the "frames" part of the NB buffer, i.e. up until the end of the transport > header. > We could use an identifier field, to match an "execute actions on packet" > sent from userspace with an NBL in our queue. > > c) create a new netlink attribute for "NBL info array" for windows, and pass > it alongside the packet. > > The aim is to solve the following: > a) whenever a packet is coming from the userspace to be outputted, it must > not lose / have unhandled any original NBL info it had. > b) do not manually handle any NBL info ourselves, unless we really have to. > c) possibly a performance concern: don't unnecessarily allocate memory for > the packet data, to queue it to the userspace, if we can preserve the > original NBLs in a queue in the kernel. > > This is obviously not an immediate concern, but needs to be thought of, for > the driver to function correctly and efficiently. > > Please let me know what you think, and, if you have any other idea how we > could do this better. > > Samuel > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6ViHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=KF3HHZ%2F4a9pn5X41aMD%2BB2MmQsHgzVwm7NuR1zPIGZ4%3D%0A&s=87d51a0bc7caf5bcb396bccd9d06e3d21eaa4ac7fc796e51328cf04d752c5a11 > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
