On Wed, Jan 04, 2017 at 03:59:19AM +0000, Jianfeng Tan wrote: > v3: > - Drop the patch to postpone driver ok sending patch, superseded it > with a bug fix to disable all virtqueues and re-init the device. > (you might wonder why not just send reset owner msg. Under my test, > it causes spinlock deadlock problem when killing the program). > - Avoid compiling error on 32-bit system for pointer convert. > - Fix a bug in patch "abstract virtio user backend ops", vhostfd is > not properly assigned. > - Fix a "MQ cannot be used" bug in v2, which is related to strip > some feature bits that vhost kernel does not recognize. > - Update release note. > > v2: (Lots of them are from yuanhan's comment) > - Add offloding feature. > - Add multiqueue support. > - Add a new patch to postpone the sending of driver ok notification. > - Put fix patch ahead of the whole patch series. > - Split original 0001 patch into 0003 and 0004 patches. > - Remove the original vhost_internal design, just add those into > struct virtio_user_dev for simplicity. > - Reword "control" to "send_request". > - Reword "host_features" to "device_features". > > In v16.07, we upstreamed a virtual device, virtio_user (with vhost-user > as the backend). The path to go with a vhost-kernel backend has been > dropped for bad performance comparing to vhost-user and code simplicity. > > But after a second thought, virtio_user + vhost-kernel is a good > candidate as an exceptional path, such as KNI, which exchanges packets > with kernel networking stack. > - maintenance: vhost-net (kernel) is upstreamed and extensively used > kernel module. We don't need any out-of-tree module like KNI. > - performance: as with KNI, this solution would use one or more > kthreads to send/receive packets from user space DPDK applications, > which has little impact on user space polling thread (except that > it might enter into kernel space to wake up those kthreads if > necessary). > - features: vhost-net is born to be a networking solution, which has > lots of networking related featuers, like multi queue, tso, multi-seg > mbuf, etc. > > Signed-off-by: Jianfeng Tan <jianfeng....@intel.com> > Sounds great. However, I think we'll need a how-to doc for this to help people get it up and running as a KNI replacement for packets to/from the kernel. Any plans to draw up such a doc? It would be good to include it in this patchset.
/Bruce
