Hello guys, I think this is a problem that both implementations suffer of: Namely, when we give a packet to the userspace, we strip off the NBL info array from it. In other words, when the packet gets back from the userspace and must be outputted to ports, all NBL info that it had before is cleared out.
We can handle manually NBL info such as checksum offload or LSO. But normally, all other NBL info in the array are important, and we cannot simply strip them away. I am thinking of alternatives to the current approach: a) keep the queue of NBLs in the driver only, and give to the userspace the keys instead. (this would be most preferable for the kernel part) AFAIK, in the current implementation, only the metadata is sent as keys in an upcall. b) if it is too much to change in userspace for approach a), perhaps we can keep the queue of NBLs in the driver, and send as "buffer to userspace" only the "frames" part of the NB buffer, i.e. up until the end of the transport header. We could use an identifier field, to match an "execute actions on packet" sent from userspace with an NBL in our queue. c) create a new netlink attribute for "NBL info array" for windows, and pass it alongside the packet. The aim is to solve the following: a) whenever a packet is coming from the userspace to be outputted, it must not lose / have unhandled any original NBL info it had. b) do not manually handle any NBL info ourselves, unless we really have to. c) possibly a performance concern: 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. This is obviously not an immediate concern, but needs to be thought of, for the driver to function correctly and efficiently. Please let me know what you think, and, if you have any other idea how we could do this better. Samuel _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
