On 1/9/2017 10:06 PM, Bruce Richardson wrote:
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 <[email protected]>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.
I was planning to do that in separate patchset. But I agree with you that it's better to do that in this patchset.
Thanks, Jianfeng
/Bruce
