* be2net: GRO for non-inet protocols @ 2013-04-05 13:20 Erik Hugne 2013-04-05 15:28 ` Eric Dumazet 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-05 13:20 UTC (permalink / raw) To: sathya.perla, subbu.seetharaman, ajit.khaparde; +Cc: netdev I'm adding GRO support for the TIPC protocol and tried to test it on a pair of HP G7 blades with Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01) NICs. However, my GRO callback is never invoked on this setup, and i suspect the be2net driver is to blame. I had a brief look at the driver, first suspecting that the do_gro check only passed for inet protocols (tcpf must be set in the be_rx_compl_info struct). However, removing this check did not change the behavior. #ethtool -i eth1 driver: be2net version: 4.4.161.0s firmware-version: 4.1.450.7 bus-info: 0000:02:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: no It works as expected on another setup with with Intel NIC's/e1000 driver. //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-05 13:20 be2net: GRO for non-inet protocols Erik Hugne @ 2013-04-05 15:28 ` Eric Dumazet 2013-04-05 15:31 ` Eric Dumazet 0 siblings, 1 reply; 16+ messages in thread From: Eric Dumazet @ 2013-04-05 15:28 UTC (permalink / raw) To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Fri, 2013-04-05 at 15:20 +0200, Erik Hugne wrote: > I'm adding GRO support for the TIPC protocol and > tried to test it on a pair of HP G7 blades with > Emulex Corporation OneConnect 10Gb NIC (be3) (rev 01) NICs. > > However, my GRO callback is never invoked on this setup, and > i suspect the be2net driver is to blame. > I had a brief look at the driver, first suspecting that the > do_gro check only passed for inet protocols (tcpf must be set > in the be_rx_compl_info struct). > However, removing this check did not change the behavior. Try following instead : diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c index 536afa2..1b9e467 100644 --- a/drivers/net/ethernet/emulex/benet/be_main.c +++ b/drivers/net/ethernet/emulex/benet/be_main.c @@ -1355,7 +1355,7 @@ static void skb_fill_rx_data(struct be_rx_obj *rxo, struct sk_buff *skb, } /* Process the RX completion indicated by rxcp when GRO is disabled */ -static void be_rx_compl_process(struct be_rx_obj *rxo, +static void be_rx_compl_process(struct be_rx_obj *rxo, struct napi_struct *napi, struct be_rx_compl_info *rxcp) { struct be_adapter *adapter = rxo->adapter; @@ -1385,7 +1385,7 @@ static void be_rx_compl_process(struct be_rx_obj *rxo, if (rxcp->vlanf) __vlan_hwaccel_put_tag(skb, rxcp->vlan_tag); - netif_receive_skb(skb); + napi_gro_receive(&napi, skb); } /* Process the RX completion indicated by rxcp when GRO is enabled */ @@ -2113,7 +2113,7 @@ static int be_process_rx(struct be_rx_obj *rxo, struct napi_struct *napi, if (do_gro(rxcp)) be_rx_compl_process_gro(rxo, napi, rxcp); else - be_rx_compl_process(rxo, rxcp); + be_rx_compl_process(rxo, napi, rxcp); loop_continue: be_rx_stats_update(rxo, rxcp); } ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-05 15:28 ` Eric Dumazet @ 2013-04-05 15:31 ` Eric Dumazet 2013-04-08 6:40 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Eric Dumazet @ 2013-04-05 15:31 UTC (permalink / raw) To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Fri, 2013-04-05 at 08:28 -0700, Eric Dumazet wrote: > /* Process the RX completion indicated by rxcp when GRO is disabled */ > -static void be_rx_compl_process(struct be_rx_obj *rxo, > +static void be_rx_compl_process(struct be_rx_obj *rxo, struct napi_struct *napi, > struct be_rx_compl_info *rxcp) > { > struct be_adapter *adapter = rxo->adapter; > @@ -1385,7 +1385,7 @@ static void be_rx_compl_process(struct be_rx_obj *rxo, > if (rxcp->vlanf) > __vlan_hwaccel_put_tag(skb, rxcp->vlan_tag); > > - netif_receive_skb(skb); > + napi_gro_receive(&napi, skb); That would be : napi_gro_receive(napi, skb); ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-05 15:31 ` Eric Dumazet @ 2013-04-08 6:40 ` Erik Hugne 2013-04-08 15:24 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-08 6:40 UTC (permalink / raw) To: Eric Dumazet; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Fri, Apr 05, 2013 at 08:31:12AM -0700, Eric Dumazet wrote: > On Fri, 2013-04-05 at 08:28 -0700, Eric Dumazet wrote: > > > /* Process the RX completion indicated by rxcp when GRO is disabled */ > > -static void be_rx_compl_process(struct be_rx_obj *rxo, > > +static void be_rx_compl_process(struct be_rx_obj *rxo, struct napi_struct *napi, > > struct be_rx_compl_info *rxcp) > > { > > struct be_adapter *adapter = rxo->adapter; > > @@ -1385,7 +1385,7 @@ static void be_rx_compl_process(struct be_rx_obj *rxo, > > if (rxcp->vlanf) > > __vlan_hwaccel_put_tag(skb, rxcp->vlan_tag); > > > > - netif_receive_skb(skb); > > + napi_gro_receive(&napi, skb); > > That would be : napi_gro_receive(napi, skb); > Thanks Eric, it works as expected after applying this. //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-08 6:40 ` Erik Hugne @ 2013-04-08 15:24 ` Erik Hugne 2013-04-08 15:51 ` Eric Dumazet 2013-04-09 14:31 ` Bandi,Sarveshwar 0 siblings, 2 replies; 16+ messages in thread From: Erik Hugne @ 2013-04-08 15:24 UTC (permalink / raw) To: Eric Dumazet; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Mon, Apr 08, 2013 at 08:40:10AM +0200, Erik Hugne wrote: > Thanks Eric, it works as expected after applying this. So, on to the next problem, now i'm getting corrupted packets from the driver instead. Would be great to get some comments from the Emulex guys regarding this. Attaching a printk trace where i log the mac header and packet data of all 0x88CA (TIPC) packets in the gro_receive routine that have an erroneous TIPC header. This happens immediately when i register myself with the device. kernel: [ 3455.608572] tipc: Activated (version 2.0.0) kernel: [ 3455.609545] NET: Registered protocol family 30 kernel: [ 3455.609547] tipc: Started in single node mode kernel: [ 3458.837149] tipc: Started in network mode kernel: [ 3458.837153] tipc: Own node address <1.1.11>, network identity 4711 kernel: [ 3458.837244] tipc: Enabled bearer <eth:eth1>, discovery domain <1.1.0>, priority 10 kernel: [ 3458.837916] tipc: Garbage packet received kernel: [ 3458.837919] tipc: packet length=56 data_len=56 kernel: [ 3458.837925] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.837929] pdata: 10 0b 00 00 00 01 9e dd 00 a0 01 00 10 0b 01 00 10 0a 00 00 00 00 01 77 05 dc 65 74 68 31 00 00 .......................w..eth1.. kernel: [ 3458.837933] pdata: 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00 50 e5 74 64 5c e6 ..................P.td\. kernel: [ 3458.837942] tipc: Established link <1.1.11:eth1-1.1.10:eth1> on network plane A kernel: [ 3458.838225] tipc: Garbage packet received kernel: [ 3458.838228] tipc: packet length=56 data_len=56 kernel: [ 3458.838232] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838236] pdata: 10 0b 00 00 00 01 9e dd 00 a1 01 00 10 0b 01 00 10 0a 00 00 00 00 00 00 00 00 65 74 68 31 00 00 ..........................eth1.. kernel: [ 3458.838239] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ kernel: [ 3458.838244] tipc: Garbage packet received kernel: [ 3458.838246] tipc: packet length=56 data_len=56 kernel: [ 3458.838249] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838254] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 ................................ kernel: [ 3458.838258] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ kernel: [ 3458.838262] tipc: Garbage packet received kernel: [ 3458.838263] tipc: packet length=60 data_len=60 kernel: [ 3458.838268] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838272] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 72 65 65 64 65 73 ..........................reedes kernel: [ 3458.838276] pdata: 6b 74 6f 70 2f 48 61 6c 2f 64 65 76 69 63 65 73 2f 6e 65 74 5f 65 34 5f 31 31 5f 35 ktop/Hal/devices/net_e4_11_5 kernel: [ 3459.976074] tipc: Garbage packet received kernel: [ 3459.976077] tipc: packet length=56 data_len=56 kernel: [ 3459.976081] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3459.976085] pdata: 10 0b 00 00 00 03 9e dd 00 a1 01 00 10 0b 01 00 10 0a 00 00 00 00 00 00 00 00 65 74 68 31 00 00 ..........................eth1.. kernel: [ 3459.976089] pdata: 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00 50 e5 74 64 5c e6 ..................P.td\. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-08 15:24 ` Erik Hugne @ 2013-04-08 15:51 ` Eric Dumazet 2013-04-09 7:55 ` Erik Hugne 2013-04-09 14:31 ` Bandi,Sarveshwar 1 sibling, 1 reply; 16+ messages in thread From: Eric Dumazet @ 2013-04-08 15:51 UTC (permalink / raw) To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Mon, 2013-04-08 at 17:24 +0200, Erik Hugne wrote: > On Mon, Apr 08, 2013 at 08:40:10AM +0200, Erik Hugne wrote: > > Thanks Eric, it works as expected after applying this. > > So, on to the next problem, now i'm getting corrupted packets > from the driver instead. Would be great to get some comments > from the Emulex guys regarding this. > > Attaching a printk trace where i log the mac header and packet data of > all 0x88CA (TIPC) packets in the gro_receive routine that have an > erroneous TIPC header. This happens immediately when i register > myself with the device. > You could check using a GRE tunnel, that the GRO support I added in recent kernel is working or not. (including the be2net patch I sent) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-08 15:51 ` Eric Dumazet @ 2013-04-09 7:55 ` Erik Hugne 2013-04-09 13:44 ` Eric Dumazet 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-09 7:55 UTC (permalink / raw) To: Eric Dumazet; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Mon, Apr 08, 2013 at 08:51:25AM -0700, Eric Dumazet wrote: > On Mon, 2013-04-08 at 17:24 +0200, Erik Hugne wrote: > > On Mon, Apr 08, 2013 at 08:40:10AM +0200, Erik Hugne wrote: > > > Thanks Eric, it works as expected after applying this. > > > > So, on to the next problem, now i'm getting corrupted packets > > from the driver instead. Would be great to get some comments > > from the Emulex guys regarding this. > > > > Attaching a printk trace where i log the mac header and packet data of > > all 0x88CA (TIPC) packets in the gro_receive routine that have an > > erroneous TIPC header. This happens immediately when i register > > myself with the device. > > > > > You could check using a GRE tunnel, that the GRO support I added in > recent kernel is working or not. (including the be2net patch I sent) I haven't found any issues with the GRO support itself. It's only on the system with Emulex NIC's that i have problems. Unfortunately, I'm stuck to kernel 3.0.61 on these machines, newer kernels won't boot due to an unresolved driver issue with the hw raid controller :/ //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-09 7:55 ` Erik Hugne @ 2013-04-09 13:44 ` Eric Dumazet 2013-04-09 14:22 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Eric Dumazet @ 2013-04-09 13:44 UTC (permalink / raw) To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Tue, 2013-04-09 at 09:55 +0200, Erik Hugne wrote: > I haven't found any issues with the GRO support itself. It's only on > the system with Emulex NIC's that i have problems. > Unfortunately, I'm stuck to kernel 3.0.61 on these machines, newer kernels > won't boot due to an unresolved driver issue with the hw raid controller :/ I suggested you try GRE tunnels on emulex NIC, to make sure the problem is not coming from your changes. Nevermind ... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-09 13:44 ` Eric Dumazet @ 2013-04-09 14:22 ` Erik Hugne 2013-04-09 14:32 ` Eric Dumazet 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-09 14:22 UTC (permalink / raw) To: Eric Dumazet; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Tue, Apr 09, 2013 at 06:44:35AM -0700, Eric Dumazet wrote: > I suggested you try GRE tunnels on emulex NIC, to make sure the problem > is not coming from your changes. Nevermind ... > I understood that, but since i could not load anything newer than 3.0.61 on them, GRO support for GRE tunnels was not included.. but anyway... I got hold of a new set of machines that i could load 3.8 and perform the GRE test on, these also use Emulex NIC's. What i found was that all packets received on the GRE device are MTU-sized, and are not GRO'd together at all. The same thing happens in a qemu environment, so maybe there's another issue with GRO for GRE.. //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-09 14:22 ` Erik Hugne @ 2013-04-09 14:32 ` Eric Dumazet 2013-04-09 14:48 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Eric Dumazet @ 2013-04-09 14:32 UTC (permalink / raw) To: Erik Hugne; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Tue, 2013-04-09 at 16:22 +0200, Erik Hugne wrote: > On Tue, Apr 09, 2013 at 06:44:35AM -0700, Eric Dumazet wrote: > > I suggested you try GRE tunnels on emulex NIC, to make sure the problem > > is not coming from your changes. Nevermind ... > > > I understood that, but since i could not load anything newer than 3.0.61 on them, > GRO support for GRE tunnels was not included.. but anyway... > I got hold of a new set of machines that i could load 3.8 and perform the GRE > test on, these also use Emulex NIC's. > What i found was that all packets received on the GRE device are MTU-sized, > and are not GRO'd together at all. The same thing happens in a qemu environment, > so maybe there's another issue with GRO for GRE.. But you included my patch ? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-09 14:32 ` Eric Dumazet @ 2013-04-09 14:48 ` Erik Hugne 0 siblings, 0 replies; 16+ messages in thread From: Erik Hugne @ 2013-04-09 14:48 UTC (permalink / raw) To: Eric Dumazet; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, netdev On Tue, Apr 09, 2013 at 07:32:31AM -0700, Eric Dumazet wrote: > But you included my patch ? Yes :) ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: be2net: GRO for non-inet protocols 2013-04-08 15:24 ` Erik Hugne 2013-04-08 15:51 ` Eric Dumazet @ 2013-04-09 14:31 ` Bandi,Sarveshwar 2013-04-09 16:31 ` Erik Hugne 1 sibling, 1 reply; 16+ messages in thread From: Bandi,Sarveshwar @ 2013-04-09 14:31 UTC (permalink / raw) To: Erik Hugne, Eric Dumazet Cc: Perla, Sathya, Seetharaman, Subramanian, Khaparde, Ajit, netdev@vger.kernel.org Erik, Checked the driver code. With the change that Eric proposed the driver does nothing more than call eth_type_trans to parse the ether protocol type and set up skb variables appropriately. Please verify that all packets are only taking the be_rx_compl_process path which calls napi_gro_receive. Apart from this I can't see anything in the driver that can cause corruption. Thanks, Sarvesh -----Original Message----- From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Erik Hugne Sent: Monday, April 08, 2013 8:54 PM To: Eric Dumazet Cc: Perla, Sathya; Seetharaman, Subramanian; Khaparde, Ajit; netdev@vger.kernel.org Subject: Re: be2net: GRO for non-inet protocols On Mon, Apr 08, 2013 at 08:40:10AM +0200, Erik Hugne wrote: > Thanks Eric, it works as expected after applying this. So, on to the next problem, now i'm getting corrupted packets from the driver instead. Would be great to get some comments from the Emulex guys regarding this. Attaching a printk trace where i log the mac header and packet data of all 0x88CA (TIPC) packets in the gro_receive routine that have an erroneous TIPC header. This happens immediately when i register myself with the device. kernel: [ 3455.608572] tipc: Activated (version 2.0.0) kernel: [ 3455.609545] NET: Registered protocol family 30 kernel: [ 3455.609547] tipc: Started in single node mode kernel: [ 3458.837149] tipc: Started in network mode kernel: [ 3458.837153] tipc: Own node address <1.1.11>, network identity 4711 kernel: [ 3458.837244] tipc: Enabled bearer <eth:eth1>, discovery domain <1.1.0>, priority 10 kernel: [ 3458.837916] tipc: Garbage packet received kernel: [ 3458.837919] tipc: packet length=56 data_len=56 kernel: [ 3458.837925] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.837929] pdata: 10 0b 00 00 00 01 9e dd 00 a0 01 00 10 0b 01 00 10 0a 00 00 00 00 01 77 05 dc 65 74 68 31 00 00 .......................w..eth1.. kernel: [ 3458.837933] pdata: 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00 50 e5 74 64 5c e6 ..................P.td\. kernel: [ 3458.837942] tipc: Established link <1.1.11:eth1-1.1.10:eth1> on network plane A kernel: [ 3458.838225] tipc: Garbage packet received kernel: [ 3458.838228] tipc: packet length=56 data_len=56 kernel: [ 3458.838232] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838236] pdata: 10 0b 00 00 00 01 9e dd 00 a1 01 00 10 0b 01 00 10 0a 00 00 00 00 00 00 00 00 65 74 68 31 00 00 ..........................eth1.. kernel: [ 3458.838239] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ kernel: [ 3458.838244] tipc: Garbage packet received kernel: [ 3458.838246] tipc: packet length=56 data_len=56 kernel: [ 3458.838249] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838254] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 ................................ kernel: [ 3458.838258] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........................ kernel: [ 3458.838262] tipc: Garbage packet received kernel: [ 3458.838263] tipc: packet length=60 data_len=60 kernel: [ 3458.838268] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3458.838272] pdata: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 72 65 65 64 65 73 ..........................reedes kernel: [ 3458.838276] pdata: 6b 74 6f 70 2f 48 61 6c 2f 64 65 76 69 63 65 73 2f 6e 65 74 5f 65 34 5f 31 31 5f 35 ktop/Hal/devices/net_e4_11_5 kernel: [ 3459.976074] tipc: Garbage packet received kernel: [ 3459.976077] tipc: packet length=56 data_len=56 kernel: [ 3459.976081] pmachdr: e4 11 5b db 24 a4 e4 11 5b d7 36 9c 88 ca ..[.$...[.6... kernel: [ 3459.976085] pdata: 10 0b 00 00 00 03 9e dd 00 a1 01 00 10 0b 01 00 10 0a 00 00 00 00 00 00 00 00 65 74 68 31 00 00 ..........................eth1.. kernel: [ 3459.976089] pdata: 00 00 00 00 00 00 00 00 00 00 04 00 00 00 04 00 00 00 50 e5 74 64 5c e6 ..................P.td\. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-09 14:31 ` Bandi,Sarveshwar @ 2013-04-09 16:31 ` Erik Hugne 2013-04-10 13:46 ` Bandi,Sarveshwar 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-09 16:31 UTC (permalink / raw) To: Bandi,Sarveshwar Cc: Eric Dumazet, Perla, Sathya, Seetharaman, Subramanian, Khaparde, Ajit, netdev@vger.kernel.org On Tue, Apr 09, 2013 at 02:31:38PM +0000, Bandi,Sarveshwar wrote: > Apart from this I can't see anything in the driver that can cause corruption. Still, that's what i'm getting.. Now I've removed almost all GRO logic, and it's flushing the queue for all packets. It looks something like this: https://gist.github.com/Hugne/5347164 Here's the output when i start up TIPC on node A (node B is already running, sending periodic ndisc requests (msg_user=13) [ 1656.912898] tipc: packet length=42 data_len=0 mac_len=14 [ 1656.912912] machdr: ff ff ff ff ff ff 10 60 4b b4 29 f0 88 ca 1656.912916] network header: 5b 50 00 28 00 00 a1 de 01 00 10 00 01 00 10 0a 00 00 12 67 00 03 00 01 10 60 4b b4 29 f0 00 00 [P.(...............g.....`K.)... [ 1656.912920] network header: 00 00 00 00 00 00 00 00 00 00 08 0a 00 86 96 0d 00 05 27 da 4b b4 45 69 00 26 88 a8 ..................'.K.Ei.&.. [ 1656.912922] tipc: msg_user=13 msg_type=0 >>># Proper ndisc message from node B [ 1657.523303] tipc: packet length=56 data_len=56 mac_len=14 [ 1657.523316] machdr: 10 60 4b b4 45 68 10 60 4b b4 29 f0 88 ca [ 1657.523320] network header: 45 00 00 34 33 a3 40 00 39 06 e8 f3 82 64 5e 8f 0a 33 3a 07 ec e5 00 16 4c 95 9a 58 47 21 b1 ed E..43.@.9....d^..3:.....L..XG!.. [ 1657.523324] network header: 80 10 01 4b c4 51 00 00 01 01 08 0a 00 86 96 51 00 05 28 1e 4b b4 45 69 00 26 88 a8 ...K.Q.........Q..(.K.Ei.&.. [ 1657.523326] tipc: msg_user=2 msg_type=1 >>># This actually looks like an IPv4 packet.. but the ethertype is TIPC.. >>># The crude "check for tipc header" passes becase it only looks at the first 3 bits >>>#(No, this did not come from the wire) [ 1657.904889] tipc: Garbage packet received [ 1657.904903] tipc: packet length=56 data_len=56 mac_len=14 [ 1657.904907] machdr: 10 60 4b b4 45 68 10 60 4b b4 29 f0 88 ca [ 1657.904911] network header: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 62 a2 48 b9 8e 05 ..........................b.H... [ 1657.904914] network header: 80 18 b8 23 61 1c 00 ea ff ff 0e 08 00 00 38 00 00 00 10 60 4b b4 45 69 00 26 88 a8 ...#a.........8....`K.Ei.&.. [ 1657.904917] tipc: msg_user=0 msg_type=0 >>># I have no idea what this is.. but it's not a TIPC packet.. >>># And it did not come from the wire either //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: be2net: GRO for non-inet protocols 2013-04-09 16:31 ` Erik Hugne @ 2013-04-10 13:46 ` Bandi,Sarveshwar 2013-04-10 13:53 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Bandi,Sarveshwar @ 2013-04-10 13:46 UTC (permalink / raw) To: Erik Hugne Cc: Eric Dumazet, Perla, Sathya, Seetharaman, Subramanian, Khaparde, Ajit, netdev@vger.kernel.org Erik, Can you check if packets are garbled when using netif_receive_skb? Or it happens only when napi_gro_receive is used? Thanks, Sarvesh -----Original Message----- From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Erik Hugne Sent: Tuesday, April 09, 2013 10:01 PM To: Bandi,Sarveshwar Cc: Eric Dumazet; Perla, Sathya; Seetharaman, Subramanian; Khaparde, Ajit; netdev@vger.kernel.org Subject: Re: be2net: GRO for non-inet protocols On Tue, Apr 09, 2013 at 02:31:38PM +0000, Bandi,Sarveshwar wrote: > Apart from this I can't see anything in the driver that can cause corruption. Still, that's what i'm getting.. Now I've removed almost all GRO logic, and it's flushing the queue for all packets. It looks something like this: https://gist.github.com/Hugne/5347164 Here's the output when i start up TIPC on node A (node B is already running, sending periodic ndisc requests (msg_user=13) [ 1656.912898] tipc: packet length=42 data_len=0 mac_len=14 [ 1656.912912] machdr: ff ff ff ff ff ff 10 60 4b b4 29 f0 88 ca 1656.912916] network header: 5b 50 00 28 00 00 a1 de 01 00 10 00 01 00 10 0a 00 00 12 67 00 03 00 01 10 60 4b b4 29 f0 00 00 [P.(...............g.....`K.)... [ 1656.912920] network header: 00 00 00 00 00 00 00 00 00 00 08 0a 00 86 96 0d 00 05 27 da 4b b4 45 69 00 26 88 a8 ..................'.K.Ei.&.. [ 1656.912922] tipc: msg_user=13 msg_type=0 >>># Proper ndisc message from node B [ 1657.523303] tipc: packet length=56 data_len=56 mac_len=14 [ 1657.523316] machdr: 10 60 4b b4 45 68 10 60 4b b4 29 f0 88 ca [ 1657.523320] network header: 45 00 00 34 33 a3 40 00 39 06 e8 f3 82 64 5e 8f 0a 33 3a 07 ec e5 00 16 4c 95 9a 58 47 21 b1 ed E..43.@.9....d^..3:.....L..XG!.. [ 1657.523324] network header: 80 10 01 4b c4 51 00 00 01 01 08 0a 00 86 96 51 00 05 28 1e 4b b4 45 69 00 26 88 a8 ...K.Q.........Q..(.K.Ei.&.. [ 1657.523326] tipc: msg_user=2 msg_type=1 >>># This actually looks like an IPv4 packet.. but the ethertype is TIPC.. >>># The crude "check for tipc header" passes becase it only looks at >>>the first 3 bits #(No, this did not come from the wire) [ 1657.904889] tipc: Garbage packet received [ 1657.904903] tipc: packet length=56 data_len=56 mac_len=14 [ 1657.904907] machdr: 10 60 4b b4 45 68 10 60 4b b4 29 f0 88 ca [ 1657.904911] network header: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 62 a2 48 b9 8e 05 ..........................b.H... [ 1657.904914] network header: 80 18 b8 23 61 1c 00 ea ff ff 0e 08 00 00 38 00 00 00 10 60 4b b4 45 69 00 26 88 a8 ...#a.........8....`K.Ei.&.. [ 1657.904917] tipc: msg_user=0 msg_type=0 >>># I have no idea what this is.. but it's not a TIPC packet.. >>># And it did not come from the wire either //E -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-10 13:46 ` Bandi,Sarveshwar @ 2013-04-10 13:53 ` Erik Hugne 2013-04-24 7:44 ` Erik Hugne 0 siblings, 1 reply; 16+ messages in thread From: Erik Hugne @ 2013-04-10 13:53 UTC (permalink / raw) To: Bandi,Sarveshwar Cc: Eric Dumazet, Perla, Sathya, Seetharaman, Subramanian, Khaparde, Ajit, netdev@vger.kernel.org On Wed, Apr 10, 2013 at 01:46:53PM +0000, Bandi,Sarveshwar wrote: > Can you check if packets are garbled when using netif_receive_skb? > Or it happens only when napi_gro_receive is used? Yes, all received packets are OK when netif_receive_skb is used. It's only when napi_gro_receive is used (from the context of be_rx_compl_process, as per Eric's patch) that i get the corrupted packets. //E ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: be2net: GRO for non-inet protocols 2013-04-10 13:53 ` Erik Hugne @ 2013-04-24 7:44 ` Erik Hugne 0 siblings, 0 replies; 16+ messages in thread From: Erik Hugne @ 2013-04-24 7:44 UTC (permalink / raw) To: Bandi,Sarveshwar Cc: Eric Dumazet, Perla, Sathya, Seetharaman, Subramanian, Khaparde, Ajit, netdev@vger.kernel.org I got my hands on some new hardware with Intel 82599EB based 10G nics (Ixgbe driver) TIPC GRO works fine with this, the 256b segments sent over a stream connection are aggregated together as shown below. [...] 09:24:36.640506 3c:19:7d:0f:de:44 (oui Unknown) > 3c:19:7d:10:1e:68 (oui Unknown), Unknown Ethertype (0x88ca), length 6950: 09:24:36.640610 3c:19:7d:0f:de:44 (oui Unknown) > 3c:19:7d:10:1e:68 (oui Unknown), Unknown Ethertype (0x88ca), length 10534: 09:24:36.640775 3c:19:7d:0f:de:44 (oui Unknown) > 3c:19:7d:10:1e:68 (oui Unknown), Unknown Ethertype (0x88ca), length 18470: 09:24:36.640863 3c:19:7d:0f:de:44 (oui Unknown) > 3c:19:7d:10:1e:68 (oui Unknown), Unknown Ethertype (0x88ca), length 2598: [...] This confirms that the problem is in be2net driver and/or firmware. //E ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2013-04-24 7:44 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-05 13:20 be2net: GRO for non-inet protocols Erik Hugne 2013-04-05 15:28 ` Eric Dumazet 2013-04-05 15:31 ` Eric Dumazet 2013-04-08 6:40 ` Erik Hugne 2013-04-08 15:24 ` Erik Hugne 2013-04-08 15:51 ` Eric Dumazet 2013-04-09 7:55 ` Erik Hugne 2013-04-09 13:44 ` Eric Dumazet 2013-04-09 14:22 ` Erik Hugne 2013-04-09 14:32 ` Eric Dumazet 2013-04-09 14:48 ` Erik Hugne 2013-04-09 14:31 ` Bandi,Sarveshwar 2013-04-09 16:31 ` Erik Hugne 2013-04-10 13:46 ` Bandi,Sarveshwar 2013-04-10 13:53 ` Erik Hugne 2013-04-24 7:44 ` Erik Hugne
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox