search for: gro

...; > > I am not sure what information would need to be preserved - > > could someone help clarify please? > > Some LRO implementations may not preserve: > > - Packet boundaries > - TSO/GSO produces packets all the same size, except possibly for the > last one. GRO therefore flushes a flow after merging a packet with > a different segment size. > - IPv4 TTL, IPv6 hop-limit, TCP timestamp > - TSO/GSO will put the same values in all packets. GRO flushes a flow > if they change. > - IPv4 fragment ID > - TSO/GSO produces consecutive...

...; > > I am not sure what information would need to be preserved - > > could someone help clarify please? > > Some LRO implementations may not preserve: > > - Packet boundaries > - TSO/GSO produces packets all the same size, except possibly for the > last one. GRO therefore flushes a flow after merging a packet with > a different segment size. > - IPv4 TTL, IPv6 hop-limit, TCP timestamp > - TSO/GSO will put the same values in all packets. GRO flushes a flow > if they change. > - IPv4 fragment ID > - TSO/GSO produces consecutive...

From: Eric Dumazet <edumazet at google.com> Straightforward patch to add GRO processing to virtio_net. napi_complete_done() usage allows more aggressive aggregation, opted-in by setting /sys/class/net/xxx/gro_flush_timeout Tested: Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, Rick Jones reported following results. One VM of each on a pair of OpenStack compu...

From: Eric Dumazet <edumazet at google.com> Straightforward patch to add GRO processing to virtio_net. napi_complete_done() usage allows more aggressive aggregation, opted-in by setting /sys/class/net/xxx/gro_flush_timeout Tested: Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, Rick Jones reported following results. One VM of each on a pair of OpenStack compu...

On Fri, Jul 31, 2015 at 06:25:17PM +0200, Eric Dumazet wrote: > From: Eric Dumazet <edumazet at google.com> > > Straightforward patch to add GRO processing to virtio_net. > > napi_complete_done() usage allows more aggressive aggregation, > opted-in by setting /sys/class/net/xxx/gro_flush_timeout > > Tested: > > Setting /sys/class/net/xxx/gro_flush_timeout to 1000 nsec, > Rick Jones reported following results. >...

...osting buffers, so if packets > were received on a physical NIC, you were dropping the packets anyway. > > It makes no difference at all, adding a cushion might make you feel > better, but its really not worth it. > > Under memory stress, it makes better sense to drop a super big GRO > packet (The one needing frag_list extension ...) > > It gives a better signal to the sender to reduce its pressure, and gives > opportunity to free more of your memory. > OK, but in that case one wonders whether we should do more to free memory? E.g. imagine that we dropped a p...

...osting buffers, so if packets > were received on a physical NIC, you were dropping the packets anyway. > > It makes no difference at all, adding a cushion might make you feel > better, but its really not worth it. > > Under memory stress, it makes better sense to drop a super big GRO > packet (The one needing frag_list extension ...) > > It gives a better signal to the sender to reduce its pressure, and gives > opportunity to free more of your memory. > OK, but in that case one wonders whether we should do more to free memory? E.g. imagine that we dropped a p...

...eserved - > >> > could someone help clarify please? > >> > >> Some LRO implementations may not preserve: > >> > >> - Packet boundaries > >> - TSO/GSO produces packets all the same size, except possibly for the > >> last one. GRO therefore flushes a flow after merging a packet with > >> a different segment size. > >> - IPv4 TTL, IPv6 hop-limit, TCP timestamp > >> - TSO/GSO will put the same values in all packets. GRO flushes a flow > >> if they change. > >> - IPv4 frag...

...eserved - > >> > could someone help clarify please? > >> > >> Some LRO implementations may not preserve: > >> > >> - Packet boundaries > >> - TSO/GSO produces packets all the same size, except possibly for the > >> last one. GRO therefore flushes a flow after merging a packet with > >> a different segment size. > >> - IPv4 TTL, IPv6 hop-limit, TCP timestamp > >> - TSO/GSO will put the same values in all packets. GRO flushes a flow > >> if they change. > >> - IPv4 frag...

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 90:E2:BA:3A:B1:A4 UP BROADCAST RUNNING PROMISC MULTIC...

On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote: > From: Ben Hutchings <bhutchings at solarflare.com> > Date: Thu, 7 Feb 2013 16:20:46 +0000 > > > If the consensus is still that we must preserve packets exactly (aside > > from the usual modifications by IP routers) then LRO should be disabled > > on all devices for which forwarding is enabled. >

On Thu, Feb 07, 2013 at 01:14:20PM -0500, David Miller wrote: > From: Ben Hutchings <bhutchings at solarflare.com> > Date: Thu, 7 Feb 2013 16:20:46 +0000 > > > If the consensus is still that we must preserve packets exactly (aside > > from the usual modifications by IP routers) then LRO should be disabled > > on all devices for which forwarding is enabled. >

...hat information would need to be preserved - >> > could someone help clarify please? >> >> Some LRO implementations may not preserve: >> >> - Packet boundaries >> - TSO/GSO produces packets all the same size, except possibly for the >> last one. GRO therefore flushes a flow after merging a packet with >> a different segment size. >> - IPv4 TTL, IPv6 hop-limit, TCP timestamp >> - TSO/GSO will put the same values in all packets. GRO flushes a flow >> if they change. >> - IPv4 fragment ID >> - TSO/...

From: Eric Dumazet <eric.dumazet at gmail.com> Date: Fri, 31 Jul 2015 18:25:17 +0200 > From: Eric Dumazet <edumazet at google.com> > > Straightforward patch to add GRO processing to virtio_net. > ... > Signed-off-by: Eric Dumazet <edumazet at google.com> > Tested-by: Rick Jones <rick.jones2 at hp.com> > Cc: "Michael S. Tsirkin" <mst at redhat.com> Michael, please review :-)

...t; >> static const struct proto_ops macvtap_socket_ops; > >> > >> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \ > >> - NETIF_F_TSO6) > >> + NETIF_F_TSO6 | NETIF_F_UFO) > >> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO) > >> #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG) > >> > >> @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb, > >> gso_type = SKB_GSO_TCPV6; > >> break; > >> case VIRTIO_NET_HDR_GSO_U...

...t; >> static const struct proto_ops macvtap_socket_ops; > >> > >> #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \ > >> - NETIF_F_TSO6) > >> + NETIF_F_TSO6 | NETIF_F_UFO) > >> #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO) > >> #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG) > >> > >> @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb, > >> gso_type = SKB_GSO_TCPV6; > >> break; > >> case VIRTIO_NET_HDR_GSO_U...

...wo up, and a d-channel established, but then I get no messages and the d-channel goes back down. I'm || this close to tracing the call states in TR-41459 to determine which side is not responding - I suspect the G3R... The second issue (due to the issue above) is that I ordered a 9 PRI trunk group from AT&T. With a "trunkgroup" configuration, I can get two of the T1's operational, but I want to add a third T1 to the trunkgroup. The problem is that there is only a primary and backup d-channel. Thus, the third T1 has no d-channel. When I bring the third span into the tr...

> OK, make sure that the two idmap.ldb files match and then run > 'samba-tool ntacl sysvolreset' on both machines and see if this cured > this problem. I did: root at dc1:~$ service sernet-samba-ad stop root at dc2:~$ service sernet-samba-ad stop root at dc2:~$ mv /var/lib/samba/private/idmap.ldb /root/idmap.ldb.bak root at dc1:~$ scp /var/lib/samba/private/idmap.ldb

...> > were received on a physical NIC, you were dropping the packets anyway. > > > > It makes no difference at all, adding a cushion might make you feel > > better, but its really not worth it. > > > > Under memory stress, it makes better sense to drop a super big GRO > > packet (The one needing frag_list extension ...) > > > > It gives a better signal to the sender to reduce its pressure, and gives > > opportunity to free more of your memory. > > > > OK, but in that case one wonders whether we should do more to free memory...

...@@ -66,7 +66,7 @@ static struct cdev macvtap_cdev; > static const struct proto_ops macvtap_socket_ops; > > #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \ > - NETIF_F_TSO6) > + NETIF_F_TSO6 | NETIF_F_UFO) > #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO) > #define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG) > > @@ -570,11 +570,14 @@ static int macvtap_skb_from_vnet_hdr(struct sk_buff *skb, > gso_type = SKB_GSO_TCPV6; > break; > case VIRTIO_NET_HDR_GSO_UDP: > - pr_warn_once("macvtap: %s: using dis...