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

Tue Aug 5 14:24:22 UTC 2014

Hello Nithin,

Even with having this IPSec problem:
a) The other NBL info items are still standing.
b) There is no IPSec worry for the cases where we do not do tunneling (I believe).
c) if we only encapsulate (tunneling) packets coming from VMs and not from manag os, then,
as I remember, all task offloading is done in VM before having reached the switch.

The only problem I see that we have is for packets coming out of VMs that, when exiting the hypervisor must be IPSec-ed is the extra bytes it will add. In this case it is possible that the hyper-v switch will do the packet fragmentation, to make the packet's size meet the MTU requirements. (because this IPSec encaspulation can happen even if we don't have our switch extension).

Sam
________________________________________
From: Nithin Raju [nithin at vmware.com]
Sent: Tuesday, August 05, 2014 5:11 PM
To: Samuel Ghinet; Ben Pfaff; Eitan Eliahu
Cc: dev at openvswitch.org
Subject: RE: [ovs-dev] Queuing packets to userspace and NBL info problem

This "issue" is not limited to missed packets only. This is applicable when there is a flow in the kernel as well.

When a VIF requests IPsec offload, and such a packet needs to be tunneled, we might need to complete the IPsec offload requested before we encap the packet to form an outer packet.

Completing the offload should be possible for the commonly used offload types. IPSec might be one of the special ones, and solving it might need some external support (NDIS?) or writing a crypto driver/library.

thanks,
Nithin

________________________________________
From: dev <dev-bounces at openvswitch.org> on behalf of Samuel Ghinet <sghinet at cloudbasesolutions.com>
Sent: Tuesday, August 5, 2014 5:08 AM
To: Ben Pfaff; Eitan Eliahu
Cc: dev at 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 [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
> https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=DgK%2FoSpTQywn8LJL8pUc%2F%2BPhijb06smFmyPlkmrbA58%3D%0A&s=1aedbc2c3875cd105a680b0a73f3135a5908a069d94375b8726e85df68486099
_______________________________________________
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=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=DgK%2FoSpTQywn8LJL8pUc%2F%2BPhijb06smFmyPlkmrbA58%3D%0A&s=1aedbc2c3875cd105a680b0a73f3135a5908a069d94375b8726e85df68486099