IPSec offload for the guests can be disabled through the Hyper-V UI or through the use of the following command: * Set-VMNetworkAdapter -VMName DC1 -IPsecOffloadMaximumSecurityAssociation 0 Then the guest synthetic NIC driver should do the encryption. Thanks, Eitan
-----Original Message----- From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com] Sent: Tuesday, August 05, 2014 7:24 AM To: Nithin Raju; Ben Pfaff; Eitan Eliahu Cc: dev@openvswitch.org Subject: RE: [ovs-dev] Queuing packets to userspace and NBL info problem 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 [nit...@vmware.com] Sent: Tuesday, August 05, 2014 5:11 PM To: Samuel Ghinet; Ben Pfaff; Eitan Eliahu Cc: dev@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-boun...@openvswitch.org> on behalf of Samuel Ghinet <sghi...@cloudbasesolutions.com> Sent: Tuesday, August 5, 2014 5:08 AM 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=ubrOpIWavCMqX4l > 4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=DgK%2FoSpTQywn8LJL8pUc%2F%2BPhi > jb06smFmyPlkmrbA58%3D%0A&s=1aedbc2c3875cd105a680b0a73f3135a5908a069d94 > 375b8726e85df68486099 _______________________________________________ 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=ubrOpIWavCMqX4l4j1LEVpTfDj%2FD5Qyn8KCoJIBGvzo%3D%0A&m=DgK%2FoSpTQywn8LJL8pUc%2F%2BPhijb06smFmyPlkmrbA58%3D%0A&s=1aedbc2c3875cd105a680b0a73f3135a5908a069d94375b8726e85df68486099 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
