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
