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

Samuel Ghinet sghinet at cloudbasesolutions.com
Tue Aug 5 16:57:42 UTC 2014


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 [nithin at vmware.com]
Sent: Tuesday, August 05, 2014 6:55 PM
To: Samuel Ghinet
Cc: Ben Pfaff; Eitan Eliahu; dev at openvswitch.org
Subject: Re: [ovs-dev] Queuing packets to userspace and NBL info problem

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



More information about the dev mailing list