search for: tun_tap_dev

As multi-queue nics were commonly used for high-end servers, current single queue based tap can not satisfy the requirement of scaling guest network performance as the numbers of vcpus increase. So the following series implements multiple queue support in tun/tap. In order to take advantages of this, a multi-queue capable driver and qemu were also needed. I just rebase the latest version of

As multi-queue nics were commonly used for high-end servers, current single queue based tap can not satisfy the requirement of scaling guest network performance as the numbers of vcpus increase. So the following series implements multiple queue support in tun/tap. In order to take advantages of this, a multi-queue capable driver and qemu were also needed. I just rebase the latest version of

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

...+ * This callback is supposed to deal with mc filter in + * _rx_ path and has nothing to do with the _tx_ path. + * In rx path we always accept everything userspace gives us. + */ + return; } #define MIN_MTU 68 @@ -244,13 +325,11 @@ static void tun_net_init(struct net_device *dev) case TUN_TAP_DEV: /* Ethernet TAP Device */ - dev->set_multicast_list = tun_net_mclist; - ether_setup(dev); - dev->change_mtu = tun_net_change_mtu; + dev->change_mtu = tun_net_change_mtu; + dev->set_multicast_list = tun_net_mclist; - /* random address already created for us by tun_s...

...+ * This callback is supposed to deal with mc filter in + * _rx_ path and has nothing to do with the _tx_ path. + * In rx path we always accept everything userspace gives us. + */ + return; } #define MIN_MTU 68 @@ -244,13 +325,11 @@ static void tun_net_init(struct net_device *dev) case TUN_TAP_DEV: /* Ethernet TAP Device */ - dev->set_multicast_list = tun_net_mclist; - ether_setup(dev); - dev->change_mtu = tun_net_change_mtu; + dev->change_mtu = tun_net_change_mtu; + dev->set_multicast_list = tun_net_mclist; - /* random address already created for us by tun_s...

...ffset) + 2); - if (gso.hdr_len > len) + if (__virtio16_to_cpu(false, gso.hdr_len) > len) return -EINVAL; offset += tun->vnet_hdr_sz; } @@ -1054,7 +1054,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile, if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) { align += NET_IP_ALIGN; if (unlikely(len < ETH_HLEN || - (gso.hdr_len && gso.hdr_len < ETH_HLEN))) + (gso.hdr_len && __virtio16_to_cpu(false, gso.hdr_len) < ETH_HLEN))) return -EINVAL; } @@ -1065,7 +1065,7 @@ static ssize_t tun_get_user(struct...

...ffset) + 2); - if (gso.hdr_len > len) + if (__virtio16_to_cpu(false, gso.hdr_len) > len) return -EINVAL; offset += tun->vnet_hdr_sz; } @@ -1054,7 +1054,7 @@ static ssize_t tun_get_user(struct tun_struct *tun, struct tun_file *tfile, if ((tun->flags & TUN_TYPE_MASK) == TUN_TAP_DEV) { align += NET_IP_ALIGN; if (unlikely(len < ETH_HLEN || - (gso.hdr_len && gso.hdr_len < ETH_HLEN))) + (gso.hdr_len && __virtio16_to_cpu(false, gso.hdr_len) < ETH_HLEN))) return -EINVAL; } @@ -1065,7 +1065,7 @@ static ssize_t tun_get_user(struct...

Hi: Here are the patches I used for testing KVM with virtio-net using TSO. There are three patches for the tun device which are basically Rusty's patches with the mmap turned into copying (for correctness). Two patches are for the virtio-net frontend, one required to support receiving SG/TSO, and the other useful for testing SG per se. The other patch is to the KVM backend to make all this

Hi: Here are the patches I used for testing KVM with virtio-net using TSO. There are three patches for the tun device which are basically Rusty's patches with the mmap turned into copying (for correctness). Two patches are for the virtio-net frontend, one required to support receiving SG/TSO, and the other useful for testing SG per se. The other patch is to the KVM backend to make all this

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

1) Turn GSO on virtio net into an all-or-nothing (keep checksumming separate). Having multiple bits is a pain: if you can't support something you should handle it in software, which is still a performance win. 2) Make VIRTIO_NET_HDR_GSO_ECN a flag in the header, so it can apply to IPv6 or v4. 3) Rename VIRTIO_NET_F_NO_CSUM to VIRTIO_NET_F_CSUM (ie. means we do checksumming). 4)

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable