[ovs-dev] Queuing packets to userspace and NBL info problem

Samuel Ghinet sghinet at cloudbasesolutions.com
Tue Aug 5 12:08:04 UTC 2014


"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 [blp at nicira.com]
Sent: Tuesday, August 05, 2014 6:19 AM
To: Eitan Eliahu
Cc: Samuel Ghinet; dev at 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-bounces at openvswitch.org] On Behalf Of Samuel Ghinet
> Sent: Sunday, August 03, 2014 10:06 AM
> To: dev at 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 at 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 at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list