similar to: consuming pre-created tap - with multiqueue

On Wed, Sep 23, 2020 at 05:44:28PM +0100, Daniel P. Berrangé wrote: > On Tue, Sep 22, 2020 at 01:48:08PM +0200, Miguel Duarte de Mora Barroso wrote: > > Hello, > > > > On KubeVirt, we are trying to pre-create a tap device, then instruct > > libvirt to consume it (via the type=ethernet , managed='no' > > attributes). > > > > It works as

On Tue, Sep 22, 2020 at 01:48:08PM +0200, Miguel Duarte de Mora Barroso wrote: > Hello, > > On KubeVirt, we are trying to pre-create a tap device, then instruct > libvirt to consume it (via the type=ethernet , managed='no' > attributes). > > It works as expected, **unless** when we create a multi-queue tap device. > > The difference when creating the tap

Hello, I'm having some doubts about consuming an existing - already configured - tap device from libvirt (with `managed='no' ` attribute set). In KubeVirt, we want to have the consumer side of the tap device run without the NET_ADMIN capability, which requires the UID / GID of the tap creator / opener to match, as per the kernel code in [0]. As such, we create the tap device (with

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

Hello all: This seires is an update of last version of multiqueue support to add multiqueue capability to both tap and virtio-net. Some kinds of tap backends has (macvatp in linux) or would (tap) support multiqueue. In such kind of tap backend, each file descriptor of a tap is a qeueu and ioctls were prodived to attach an exist tap file descriptor to the tun/tap device. So the patch let qemu to

With Libvirt under modern kernels, you can't use <interface type='ethernet'> unless QEMU is running as root. Running qemu as root is not ideal, but I was able to track down the issue to this linux change: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 Which means that if you're seeing errors like this:

Hi all, Heketi v6.0.0 is now available [1]. This is the new stable version of Heketi. Older versions are discontinued. The main additions in this release are the block-volume API, a great deal of stabilization to prevent inconsistent database and out-of-sync situations, and tooling to do disaster recovery when the database is bad. Changelog * Add support for gluster-block volumes * Add device

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

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

Hi, This patches introduce virtio_net_hdr_{from,to}_skb functions for conversion of GSO information between skb and virtio_net_hdr. Mike Rapoport (6): virtio_net: add _UAPI prefix to virtio_net header guards virtio_net: introduce virtio_net_hdr_{from,to}_skb macvtap: use common code for virtio_net_hdr and skb GSO conversion tuntap: use common code for virtio_net_hdr and skb GSO

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint (has_data_valid) and set it only on the receiving path. Cc: Rolf Neugebauer <rolf.neugebauer at docker.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/macvtap.c | 2 +-

Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too, fixing this by adding a hint (has_data_valid) and set it only on the receiving path. Cc: Rolf Neugebauer <rolf.neugebauer at docker.com> Signed-off-by: Jason Wang <jasowang at redhat.com> --- drivers/net/macvtap.c | 2 +-

There's no need for the guest to validate the checksum if it have been validated by host nics. So this patch introduces a new flag - VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum examing in guest. The backend (tap/macvtap) may set this flag when met skbs with CHECKSUM_UNNECESSARY to save cpu utilization. No feature negotiation is needed as old driver just ignore this flag.

There's no need for the guest to validate the checksum if it have been validated by host nics. So this patch introduces a new flag - VIRTIO_NET_HDR_F_DATA_VALID which is used to bypass the checksum examing in guest. The backend (tap/macvtap) may set this flag when met skbs with CHECKSUM_UNNECESSARY to save cpu utilization. No feature negotiation is needed as old driver just ignore this flag.

Hi I am using Libvirt 1.1.2 with Openstack Havana (RC2, nova-network) and openvswitch 1.4.2+git20120612-9.1. Libvirt vif driver ( nova.virt.libvirt.vif.LibvirtGenericVIFDriver) generates config likes this: <interface type='bridge'> <mac address='fa:16:3e:44:30:a4'/> <source bridge='br0'/> <model type='virtio'/>

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next for safety. In the

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next for safety. In the