Re: [PATCH net-next 0/3] vhost_net: access ptr ring using tap recvmsg

From: Jason Wang <jasowang@redhat.com>
To: prashantbhole.linux@gmail.com,
	"Michael S . Tsirkin" <mst@redhat.com>,
	"David S . Miller" <davem@davemloft.net>
Cc: David Ahern <dsahern@gmail.com>,
	kvm@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net-next 0/3] vhost_net: access ptr ring using tap recvmsg
Date: Sat, 12 Oct 2019 15:57:21 +0800	[thread overview]
Message-ID: <8f319697-34e1-fde5-65f3-7db8dc723982@redhat.com> (raw)
In-Reply-To: <20191012015357.1775-1-prashantbhole.linux@gmail.com>

On 2019/10/12 上午9:53, prashantbhole.linux@gmail.com wrote:
> From: Prashant Bhole <prashantbhole.linux@gmail.com>
>
> vhost_net needs to peek tun packet sizes to allocate virtio buffers.
> Currently it directly accesses tap ptr ring to do it. Jason Wang
> suggested to achieve this using msghdr->msg_control and modifying the
> behavior of tap recvmsg.

Note this may use more indirect calls, this could be optimized in the 
future by doing XDP/skb receiving by vhost_net its own.

>
> This change will be useful in future in case of virtio-net XDP
> offload. Where packets will be XDP processed in tap recvmsg and vhost
> will see only non XDP_DROP'ed packets.
>
> Patch 1: reorganizes the tun_msg_ctl so that it can be extended by
>   the means of different commands. tap sendmsg recvmsg will behave
>   according to commands.
>
> Patch 2: modifies recvmsg implementation to produce packet pointers.
>   vhost_net uses recvmsg API instead of ptr_ring_consume().
>
> Patch 3: removes ptr ring usage in vhost and functions those export
>   ptr ring from tun/tap.
>
> Prashant Bhole (3):
>    tuntap: reorganize tun_msg_ctl usage
>    vhost_net: user tap recvmsg api to access ptr ring
>    tuntap: remove usage of ptr ring in vhost_net
>
>   drivers/net/tap.c      | 44 ++++++++++++++---------
>   drivers/net/tun.c      | 45 +++++++++++++++---------
>   drivers/vhost/net.c    | 79 ++++++++++++++++++++++--------------------
>   include/linux/if_tun.h |  9 +++--
>   4 files changed, 103 insertions(+), 74 deletions(-)

It would be helpful that if you can share some performance numbers here.

Thanks