similar to: Flow Control and Port Mirroring Revisited

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

UFO support in the kernel applies to both IPv4 and IPv6 protocols with the same device feature. However some devices may not be able to support one of the offloads. For this we split the UFO offload feature into 2 pieces. NETIF_F_UFO now controlls the IPv4 part and this series introduces NETIF_F_UFO6. As a result of this work, we can now re-enable NETIF_F_UFO on virtio_net devices and restore

As I'm new to qemu/kvm, to figure out how networking performance can be improved, I went over the code and took some notes. As I did this, I tried to record ideas from recent discussions and ideas that came up on improving performance. Thus this list. This includes a partial overview of networking code in a virtual environment, with focus on performance: I'm only interested in sending

As I'm new to qemu/kvm, to figure out how networking performance can be improved, I went over the code and took some notes. As I did this, I tried to record ideas from recent discussions and ideas that came up on improving performance. Thus this list. This includes a partial overview of networking code in a virtual environment, with focus on performance: I'm only interested in sending

Various drivers do skb_orphan() because they do not free transmitted skbs in a timely manner (causing apps which hit their socket limits to stall, socket close to hang, etc.). DaveM points out that there are advantages to doing it generally (it's more likely to be on same CPU than after xmit), and I couldn't find any new starvation issues in simple benchmarking here. This patch adds

Various drivers do skb_orphan() because they do not free transmitted skbs in a timely manner (causing apps which hit their socket limits to stall, socket close to hang, etc.). DaveM points out that there are advantages to doing it generally (it's more likely to be on same CPU than after xmit), and I couldn't find any new starvation issues in simple benchmarking here. This patch adds

Hello. On 12/17/2014 09:20 PM, Vladislav Yasevich wrote: > Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks > to handel UFO6 flows. > Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, > so we need to continue to handle them correclty. > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- >

Hello. On 12/17/2014 09:20 PM, Vladislav Yasevich wrote: > Since UFO6 packets can now be identified by SKB_GSO_UDP6, add proper checks > to handel UFO6 flows. > Legacy applications may still have UFO6 packets identified by SKB_GSO_UDP, > so we need to continue to handle them correclty. > Signed-off-by: Vladislav Yasevich <vyasevic at redhat.com> > --- >

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an

On Thursday 01 May 2008 00:31:46 Mark McLoughlin wrote: > virtio_net currently only frees old transmit skbs just > before queueing new ones. If the queue is full, it then > enables interrupts and waits for notification that more > work has been performed. Hi Mark, This patch is fine, but it's better to do it from skb_xmit_done(). Of course, this is usually called from an

[ CCed VHOST contacts ] On Thu, Oct 28, 2010 at 01:22:02PM -0700, Jesse Gross wrote: > On Thu, Oct 28, 2010 at 4:54 AM, Simon Horman <horms at verge.net.au> wrote: > > My reasoning is that in the non-mirroring case the guest is > > limited by the external interface through wich the packets > > eventually flow - that is 1Gbit/s. But in the mirrored either > > there

[ CCed VHOST contacts ] On Thu, Oct 28, 2010 at 01:22:02PM -0700, Jesse Gross wrote: > On Thu, Oct 28, 2010 at 4:54 AM, Simon Horman <horms at verge.net.au> wrote: > > My reasoning is that in the non-mirroring case the guest is > > limited by the external interface through wich the packets > > eventually flow - that is 1Gbit/s. But in the mirrored either > > there

Hi Ian, Today i fired up an old VM with a bittorrent client, trying to download some torrents. I seem to be hitting the unlikely case of "xennet: skb rides the rocket: xx slots" and this results in some dropped packets in domU, I don''t see any warnings in dom0. I have added some extra info, but i don''t have enough knowledge if this could/should be prevented from

On 02/26/2014 02:32 PM, Qin Chuanyu wrote: > On 2014/2/26 13:53, Jason Wang wrote: >> On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>> On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >>>> We used to stop the handling of tx when the number of pending DMAs >>>> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation

On 02/26/2014 02:32 PM, Qin Chuanyu wrote: > On 2014/2/26 13:53, Jason Wang wrote: >> On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: >>> On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >>>> We used to stop the handling of tx when the number of pending DMAs >>>> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation

On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: > On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >> We used to stop the handling of tx when the number of pending DMAs >> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation >> of both host and guest. But it was too aggressive in some cases, since >> any delay or blocking of a single packet

On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote: > On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote: >> We used to stop the handling of tx when the number of pending DMAs >> exceeds VHOST_MAX_PEND. This is used to reduce the memory occupation >> of both host and guest. But it was too aggressive in some cases, since >> any delay or blocking of a single packet

virtio net used to unlink skbs from send queues on error, but ever since 48925e372f04f5e35fec6269127c62b2c71ab794 we do not do this. This causes guest data corruption and crashes with vhost since net core can requeue the skb or free it without it being taken off the list. This patch fixes this by queueing the skb after successfull transmit. Signed-off-by: Michael S. Tsirkin <mst at

virtio net used to unlink skbs from send queues on error, but ever since 48925e372f04f5e35fec6269127c62b2c71ab794 we do not do this. This causes guest data corruption and crashes with vhost since net core can requeue the skb or free it without it being taken off the list. This patch fixes this by queueing the skb after successfull transmit. Signed-off-by: Michael S. Tsirkin <mst at

This patch updates the network emulation packet scheduler. * name changed from delay to netem since it does more than just delay * Catalin''s merged code to do packet reordering * uses a socket queue''s directly rather than layering on qdisc(fifo) because this is used in performance tests. * adds placeholder in API for future enhancements (rate and duplicate).