ssp0
commented
9 years ago I think the scope of this is a bit broader than just losing NBL info, from what I understand by reading the email thread - http://openvswitch.org/pipermail/dev/2014-August/043499.html. Could you please appropriately edit the summary to reflect that?
Also, since there is no full-blown support for offloads in our driver, this is probably an enhancement and not a bug.
Samuel-Ghinet
The NBL info may hold very important information. And it appears that some structs in the NBL info cannot be handled in the driver. The consequences for lacking one info struct or another may vary, and it is not always predictable.
For NBL info structs that can be handled in driver, it may be an additional overhead, if the NBL info can be later done at Packet Execute (i.e. packet sent back from userspace).
The aim should be: a) whenever a packet is coming from the userspace to be outputted, it should not lose / have unhandled any original NBL info it had. b) It is possible we cannot handle all NBL info structs in a NBL in the driver. c) do not manually handle any NBL info ourselves, unless we really have to. d) possibly a performance concern: If we can, 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. e) it should take into account the fact that some packets may get sent to an OpenFlow controller. f) the kernel cannot assume that the packet will be returned to it, nor, if it does, that it will be returned to it unmodified. e) take into account IPSec and IPSec offload: the driver was never tested with IPSec offloading. It is possible we can get away by simply disabling the IPSec offloading from within the hypervisor.