Hello Nithin, [QUOTE] > 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).
Yes and No. In general, we don't need to complete offloads if: - if a packet is bound to another VIF on the same host OR - if the packet is being sent out on the wire using a patch port (ie. no tunneling).[/QUOTE] Your second point is the same as my "b)" I think :) As about the first, do you still mean about b)? or about a)? Sorry, I don't understand what you want to say. "But, I am not sure if NDIS stack behaves if a VIF receives a packet where the IPSec offload is not completed." My guess is that IPSec becomes disabled. I don't know very much about IPSec, but I know it's something about security. And I'm thinking, perhaps being disabled is not always a nice thing to happen. [QUOTE]Yes, if completing the offload bloats up the size of the packet beyond what the Hyper-V switche's MTU, the packet will get dropped. But, this is a problem with our without OVS in the picture, and should be treated as a mis-configuration.[/QUOTE] I am convinced that the guys implementing the hyper-v switch did not leave the functionality broken if someone decided to use IPSec. That's a point I was trying to say. Sam ________________________________________ From: Nithin Raju [nit...@vmware.com] Sent: Tuesday, August 05, 2014 6:55 PM To: Samuel Ghinet Cc: Ben Pfaff; Eitan Eliahu; dev@openvswitch.org Subject: Re: [ovs-dev] Queuing packets to userspace and NBL info problem On Aug 5, 2014, at 7:24 AM, Samuel Ghinet <sghi...@cloudbasesolutions.com> wrote: > 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). Yes and No. In general, we don't need to complete offloads if: - if a packet is bound to another VIF on the same host OR - if the packet is being sent out on the wire using a patch port (ie. no tunneling). But, I am not sure if NDIS stack behaves if a VIF receives a packet where the IPSec offload is not completed. I am not sure if a destination VIF accepts NBLs if offloads are not completed, provided the NBL is originating on the same host. > 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. Yes. If we disable offloading within the VM (as a workaround), we don't run into the issues you are alluding to if the packet is missed or if the it is encapsulated. The VM would have taken care of completing the offload. > 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). Yes, if completing the offload bloats up the size of the packet beyond what the Hyper-V switche's MTU, the packet will get dropped. But, this is a problem with our without OVS in the picture, and should be treated as a mis-configuration. In general, you have brought up a very good point about how to complete 'complex' offloads in OVS - either in the missed packet case or otherwise. We'll have to fix this in the long term. Pls. log an issue for this, and we will tackle this. -- Nithin _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
