search for: napi_gro_receive

Hi All, I am sure this has been answered somewhere in the list in the past, but I can''t find it. I was wondering if the linux guest netfront driver has GRO support in it. tcpdump shows packets coming in with 1500 bytes, although the eth0 in dom0 and the vif corresponding to the linux guest in dom0 is showing that they receive large packet: In dom0: eth0 Link encap:Ethernet HWaddr

...OTOH? Hi Willem. No, think about GRO(In the GRO we don't know packets will be forwarded to other ports or to local). The call tree as below: + 5.41% secondary_startup_64 - 1.22% ret_from_fork .... net_rx_action napi_poll virtnet_poll virtnet_receive napi_gro_receive dev_gro_receive inet_gro_receive tcp4_gro_receive __skb_gro_checksum_complete skb_checksum __skb_checksum csum_partial do_csum - 1.13% do_csum $ brctl show bridge name bridge id STP enabled interfaces br0 8000.001122330001 no eth1...

...0x18c/0x250 [bridge] [<ffffffff81445709>] ? __netif_receive_skb+0x529/0x750 [<ffffffff814397da>] ? __alloc_skb+0x7a/0x180 [<ffffffff814492f8>] ? netif_receive_skb+0x58/0x60 [<ffffffff81449400>] ? napi_skb_finish+0x50/0x70 [<ffffffff8144ab79>] ? napi_gro_receive+0x39/0x50 [<ffffffffa016887f>] ? bnx2x_rx_int+0x83f/0x1630 [bnx2x] [<ffffffff810608dc>] ? perf_event_task_sched_out+0x4c/0x70 [<ffffffffa01698ae>] ? bnx2x_poll+0x23e/0x2f0 [bnx2x] [<ffffffff8144ac93>] ? net_rx_action+0x103/0x2f0 [<ffffffff8107a811...

...b/drivers/net/virtio_net.c index 7fbca37a1adf..66f08f622dc6 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -518,7 +518,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, skb_mark_napi_id(skb, &rq->napi); - netif_receive_skb(skb); + napi_gro_receive(&rq->napi, skb); return; frame_err: @@ -756,7 +756,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget) /* Out of packets? */ if (received < budget) { r = virtqueue_enable_cb_prepare(rq->vq); - napi_complete(napi); + napi_complete_done(napi, received); if...

...b/drivers/net/virtio_net.c index 7fbca37a1adf..66f08f622dc6 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -518,7 +518,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, skb_mark_napi_id(skb, &rq->napi); - netif_receive_skb(skb); + napi_gro_receive(&rq->napi, skb); return; frame_err: @@ -756,7 +756,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget) /* Out of packets? */ if (received < budget) { r = virtqueue_enable_cb_prepare(rq->vq); - napi_complete(napi); + napi_complete_done(napi, received); if...

...[ffff880010ba3c58] ip_forward at ffffffff81306ede #19 [ffff880010ba3c98] ip_rcv_finish at ffffffff81305125 #20 [ffff880010ba3cd8] ip_rcv at ffffffff813056ad #21 [ffff880010ba3d18] netif_receive_skb at ffffffff812d787a #22 [ffff880010ba3d78] napi_skb_finish at ffffffff812d7c68 #23 [ffff880010ba3d98] napi_gro_receive at ffffffff812d8179 #24 [ffff880010ba3db8] ixgbe_poll at ffffffffa00be1cc #25 [ffff880010ba3e68] net_rx_action at ffffffff812d830e #26 [ffff880010ba3ec8] __do_softirq at ffffffff8105c726 #27 [ffff880010ba3f38] call_softirq at ffffffff8100d15c #28 [ffff880010ba3f50] do_softirq at ffffffff8100e995 #2...

...7a1adf..66f08f622dc6 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -518,7 +518,7 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, > > skb_mark_napi_id(skb, &rq->napi); > > - netif_receive_skb(skb); > + napi_gro_receive(&rq->napi, skb); > return; > > frame_err: > @@ -756,7 +756,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget) > /* Out of packets? */ > if (received < budget) { > r = virtqueue_enable_cb_prepare(rq->vq); > - napi_complete(napi); >...

...rx_syncp); + ret = skb->len; if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) skb->ip_summed = CHECKSUM_UNNECESSARY; @@ -775,11 +772,12 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, ntohs(skb->protocol), skb->len, skb->pkt_type); napi_gro_receive(&rq->napi, skb); - return; + return ret; frame_err: dev->stats.rx_frame_errors++; dev_kfree_skb(skb); + return 0; } static unsigned int virtnet_get_headroom(struct virtnet_info *vi) @@ -994,12 +992,13 @@ static void refill_work(struct work_struct *work) static int virtnet_rece...

...rx_syncp); + ret = skb->len; if (hdr->hdr.flags & VIRTIO_NET_HDR_F_DATA_VALID) skb->ip_summed = CHECKSUM_UNNECESSARY; @@ -775,11 +772,12 @@ static void receive_buf(struct virtnet_info *vi, struct receive_queue *rq, ntohs(skb->protocol), skb->len, skb->pkt_type); napi_gro_receive(&rq->napi, skb); - return; + return ret; frame_err: dev->stats.rx_frame_errors++; dev_kfree_skb(skb); + return 0; } static unsigned int virtnet_get_headroom(struct virtnet_info *vi) @@ -994,12 +992,13 @@ static void refill_work(struct work_struct *work) static int virtnet_rece...

...p kernel: [<ffffffff81490d3a>] ? tcp4_gro_receive+0x5a/0xd0 Oct 18 03:10:52 backup kernel: [<ffffffff8143cd78>] ? netif_receive_skb+0x58/0x60 Oct 18 03:10:52 backup kernel: [<ffffffff8143ce80>] ? napi_skb_finish+0x50/0x70 Oct 18 03:10:52 backup kernel: [<ffffffff8143f3b9>] ? napi_gro_receive+0x39/0x50 Oct 18 03:10:52 backup kernel: [<ffffffffa025af2f>] ? bnx2_poll_work+0xd4f/0x1270 [bnx2] Oct 18 03:10:52 backup kernel: [<ffffffff810632bb>] ? enqueue_task_fair+0xb/0x100 Oct 18 03:10:52 backup kernel: [<ffffffffa025b579>] ? bnx2_poll+0x69/0x2d8 [bnx2] Oct 18 03:10:52 ba...

...782.525604] ? ip_rcv_finish+0x400/0x400 [ 782.525606] ip_rcv+0x26c/0x380 [ 782.525610] __netif_receive_skb_core+0x3a0/0xb10 [ 782.525629] ? inet_gro_receive+0x23c/0x2b0 [ 782.525631] ? netif_receive_skb_internal+0x24/0xb0 [ 782.525633] netif_receive_skb_internal+0x24/0xb0 [ 782.525635] napi_gro_receive+0xb8/0xe0 [ 782.525638] xennet_poll+0x676/0xb40 [xen_netfront] [ 782.525641] net_rx_action+0x139/0x3a0 [ 782.525644] __do_softirq+0xde/0x2b4 [ 782.525646] irq_exit+0xae/0xb0 [ 782.525651] xen_evtchn_do_upcall+0x2c/0x40 [ 782.525653] xen_hvm_callback_vector+0x7d/0x90 [ 782.525654] <...

...__read_once_size include/linux/compiler.h:188 [inline] > __netif_receive_skb_core+0x2e09/0x3680 net/core/dev.c:4657 > __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:4807 > netif_receive_skb_internal+0x12e/0x680 net/core/dev.c:4881 > napi_skb_finish net/core/dev.c:5270 [inline] > napi_gro_receive+0x465/0x5c0 net/core/dev.c:5301 > receive_buf+0xc97/0x2bf0 drivers/net/virtio_net.c:996 > virtnet_receive drivers/net/virtio_net.c:1252 [inline] > virtnet_poll+0x3d5/0xe3d drivers/net/virtio_net.c:1334 > napi_poll net/core/dev.c:5926 [inline] > net_rx_action+0x7a5/0x1950 net/cor...

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> Open vSwitch and Linux bridge will disable LRO of the interface when this interface added to them. Now when disable the LRO, the virtio-net csum is disable too. That drops the forwarding performance. Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO") Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Jason Wang

From: Tonghao Zhang <xiangxia.m.yue at gmail.com> Open vSwitch and Linux bridge will disable LRO of the interface when this interface added to them. Now when disable the LRO, the virtio-net csum is disable too. That drops the forwarding performance. Fixes: a02e8964eaf9 ("virtio-net: ethtool configurable LRO") Cc: Michael S. Tsirkin <mst at redhat.com> Cc: Jason Wang

...2 01:29:39 xenhost-rack1 kernel: [4437064.012165] [<ffffffff81479ec5>] ? __netdev_alloc_skb+0x1d/0x3a Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012169] [<ffffffff814824bc>] napi_skb_finish+0x24/0x38 Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012172] [<ffffffff81482900>] napi_gro_receive+0x2a/0x2f Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012175] [<ffffffff8135aa86>] e1000_receive_skb+0x43/0x4b Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012178] [<ffffffff8135c557>] e1000_clean_rx_irq+0x212/0x2b7 Dec 2 01:29:39 xenhost-rack1 kernel: [4437064.012181] [<ffffff...

...t;0> [<ffffffff804a57b6>] skb_release_data+0x9b/0xac [<ffffffff804a5e18>] skb_release_all+0x19/0x1e [<ffffffff804a5636>] __kfree_skb+0x11/0x78 [<ffffffff804a56c5>] kfree_skb+0x28/0x2a [<ffffffff804abc91>] netif_receive_skb+0x2c6/0x2eb [<ffffffff804ac067>] napi_gro_receive+0x26/0x3a [<ffffffffa000c1ab>] e1000_receive_skb+0x45/0x4d [e1000e] [<ffffffffa000f31d>] e1000_clean_rx_irq+0x225/0x2c5 [e1000e] [<ffffffffa000e925>] e1000_clean+0x96/0x250 [e1000e] [<ffffffff803d70a6>] ? pirq_unmask_notify+0x35/0x8d [<ffffffff8020e1e2>] ? check_e...

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

...t kernel: [<ffffffff8149813a>] ? tcp4_gro_receive+0x5a/0xd0 Jun 13 09:41:18 myhost kernel: [<ffffffff81444068>] ? netif_receive_skb+0x58/0x60 Jun 13 09:41:18 myhost kernel: [<ffffffff81444170>] ? napi_skb_finish+0x50/0x70 Jun 13 09:41:18 myhost kernel: [<ffffffff814466a9>] ? napi_gro_receive+0x39/0x50 Jun 13 09:41:18 myhost kernel: [<ffffffffa01303b4>] ? igb_poll+0x864/0xb00 [igb] Jun 13 09:41:18 myhost kernel: [<ffffffff810606ec>] ? rebalance_domains+0x3cc/0x5a0 Jun 13 09:41:18 myhost kernel: [<ffffffff814467c3>] ? net_rx_action+0x103/0x2f0 Jun 13 09:41:18 myhost ker...

Hello, I''m facing a strange issue with network card PCI passthrough on my openwrt test domU. - With network PCI passthrough, DNS lookup failed for some domains (exemple, google.com) but not for other (free.fr my ISP, or my domain jbfavre.org). I can ping an IP address without any problem. - Starting domU as a "normal" (ie without PCI passthrough), no problem. As far as I can