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

[Nithin Raju]

On Aug 5, 2014, at 7:24 AM, Samuel Ghinet <sghinet at 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