Yes, the packet can be delivered to the OF controller and the kernel cannot assume that the packet will be returned to it or returned to it unmodified. Eitan
-----Original Message----- From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Samuel Ghinet Sent: Tuesday, August 05, 2014 7:15 AM To: dev@openvswitch.org Subject: [ovs-dev] FW: Queuing packets to userspace and NBL info problem " in general not all packets are returned to back to the kernel" What does it mean for this case: will the packet be dropped (i.e. not sent at all), or it will be passed to the kernel of a different machine, for it to send it? Basically, if "won't be returned back to the kernel" means dropped, I guess that's ok. Sam ________________________________________ From: Samuel Ghinet Sent: Tuesday, August 05, 2014 3:08 PM To: Ben Pfaff; Eitan Eliahu Cc: dev@openvswitch.org Subject: RE: [ovs-dev] Queuing packets to userspace and NBL info problem "Most of the items on the list seem to be related to offloads. The kernel module should complete offloads before it passes the packet to userspace." The issue with IPSec is that, as I know hyper-v switch extensions are not supposed to implement their own IPSec. I mean, normally, this IPSec offload struct is merely some contextual information required by (the miniport driver?) to know a) that it must do IPSec; b) the parameters / options / for IPSec. I personally believe we can't simply handle every specific case of each NBL info. Sam ________________________________________ From: Ben Pfaff [b...@nicira.com] Sent: Tuesday, August 05, 2014 6:19 AM To: Eitan Eliahu Cc: Samuel Ghinet; dev@openvswitch.org Subject: Re: [ovs-dev] Queuing packets to userspace and NBL info problem 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/mail > man/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6V > iHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=KF3HHZ%2F4a9pn5X41aMD%2BB2MmQsHgz > Vwm7NuR1zPIGZ4%3D%0A&s=87d51a0bc7caf5bcb396bccd9d06e3d21eaa4ac7fc796e5 > 1328cf04d752c5a11 _______________________________________________ > dev mailing list > dev@openvswitch.org > https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mail > man/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=yTvML8OxA42Jb6V > iHe7fUXbvPVOYDPVq87w43doxtlY%3D%0A&m=YJ630Uxr2zLKvHaNGjs4iFRo%2FGU8zU4 > Kf0Fsrjhpluo%3D%0A&s=fd6db68825e1c47548ceea7fa1ffcacecce5e36a43a66ec4e > 4fb871a0636da53 _______________________________________________ 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=YJ630Uxr2zLKvHaNGjs4iFRo%2FGU8zU4Kf0Fsrjhpluo%3D%0A&s=fd6db68825e1c47548ceea7fa1ffcacecce5e36a43a66ec4e4fb871a0636da53 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
