similar to: [PATCH RFC] tun: fix sparse warnings for virtio headers

This patch introduces to a new tun/tap specific msg_control: #define TUN_MSG_UBUF 1 #define TUN_MSG_PTR 2 struct tun_msg_ctl { int type; void *ptr; }; This allows us to pass different kinds of msg_control through sendmsg(). The first supported type is ubuf (TUN_MSG_UBUF) which will be used by the existed vhost_net zerocopy code. The second is XDP buff, which allows vhost_net to

On Thu, Sep 06, 2018 at 12:05:23PM +0800, Jason Wang wrote: > This patch introduces to a new tun/tap specific msg_control: > > #define TUN_MSG_UBUF 1 > #define TUN_MSG_PTR 2 > struct tun_msg_ctl { > int type; > void *ptr; > }; > > This allows us to pass different kinds of msg_control through > sendmsg(). The first supported type is ubuf

On Wed, Sep 23, 2015 at 07:45:08PM +0100, David Woodhouse wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > > Since virtio_legacy_is_little_endian() is a very long identifier, > define a VIO_LE macro and use

On Wed, Sep 23, 2015 at 07:45:08PM +0100, David Woodhouse wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > > Since virtio_legacy_is_little_endian() is a very long identifier, > define a VIO_LE macro and use

On Thu, Sep 24, 2015 at 09:25:45AM +0200, Greg Kurz wrote: > On Wed, 23 Sep 2015 19:45:08 +0100 > David Woodhouse <dwmw2 at infradead.org> wrote: > > > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > > accessors") accidentally changed the virtio_net header used by > > AF_PACKET with PACKET_VNET_HDR from host-endian to

On Wed, 23 Sep 2015 19:45:08 +0100 David Woodhouse <dwmw2 at infradead.org> wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > Hi David, Oops my bad... I obviously overlooked this one when adding

On Wed, 23 Sep 2015 19:45:08 +0100 David Woodhouse <dwmw2 at infradead.org> wrote: > Commit 7d82410950aa ("virtio: add explicit big-endian support to memory > accessors") accidentally changed the virtio_net header used by > AF_PACKET with PACKET_VNET_HDR from host-endian to big-endian. > Hi David, Oops my bad... I obviously overlooked this one when adding

Now that UFO is split into v4 and v6 parts, we can bring back v4 support without any trouble. Continue to handle legacy applications by selecting the IPv6 fragment id but do not change the gso type. Thist makes sure that two legacy VMs may still communicate. Based on original work from Ben Hutchings. Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio") CC: Ben Hutchings

Now that UFO is split into v4 and v6 parts, we can bring back v4 support without any trouble. Continue to handle legacy applications by selecting the IPv6 fragment id but do not change the gso type. Thist makes sure that two legacy VMs may still communicate. Based on original work from Ben Hutchings. Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio") CC: Ben Hutchings

On Tue, Nov 11, 2014 at 05:12:58PM +0000, Ben Hutchings wrote: > This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for > the tap drivers, but leaves UFO disabled in virtio_net. > > libvirt at least assumes that tap features will never be dropped > in new kernel versions, and doing so prevents migration of VMs to > the never kernel version while they are running with

On 12/18/2014 12:51 AM, Jason Wang wrote: > > > ----- Original Message ----- >> Now that UFO is split into v4 and v6 parts, we can bring >> back v4 support without any trouble. >> >> Continue to handle legacy applications by selecting the >> IPv6 fragment id but do not change the gso type. Thist >> makes sure that two legacy VMs may still

On 12/18/2014 12:51 AM, Jason Wang wrote: > > > ----- Original Message ----- >> Now that UFO is split into v4 and v6 parts, we can bring >> back v4 support without any trouble. >> >> Continue to handle legacy applications by selecting the >> IPv6 fragment id but do not change the gso type. Thist >> makes sure that two legacy VMs may still

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that UFO functionality can correctly track the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that UFO functionality can correctly track the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that GSO functionality can correctly track if the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 3d0ad09412ffe00c9afa201d01effdb6023d09b4. Now that GSO functionality can correctly track if the fragment id has been selected and select a fragment id if necessary, we can re-enable UFO on tap/macvap and virtio devices. Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> --- drivers/net/macvtap.c | 13 ++++++++----- drivers/net/tun.c | 19

This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for the tap drivers, but leaves UFO disabled in virtio_net. libvirt at least assumes that tap features will never be dropped in new kernel versions, and doing so prevents migration of VMs to the never kernel version while they are running with virtio net devices. Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")

This reverts commit 88e0e0e5aa722b193c8758c8b45d041de5316924 for the tap drivers, but leaves UFO disabled in virtio_net. libvirt at least assumes that tap features will never be dropped in new kernel versions, and doing so prevents migration of VMs to the never kernel version while they are running with virtio net devices. Fixes: 88e0e0e5aa7a ("drivers/net: Disable UFO through virtio")

We can only process 1 packet at one time during sendmsg(). This often lead bad cache utilization under heavy load. So this patch tries to do some batching during rx before submitting them to host network stack. This is done through accepting MSG_MORE as a hint from sendmsg() caller, if it was set, batch the packet temporarily in a linked list and submit them all once MSG_MORE were cleared. Tests

We can only process 1 packet at one time during sendmsg(). This often lead bad cache utilization under heavy load. So this patch tries to do some batching during rx before submitting them to host network stack. This is done through accepting MSG_MORE as a hint from sendmsg() caller, if it was set, batch the packet temporarily in a linked list and submit them all once MSG_MORE were cleared. Tests