VLAN does not work with niu driver
Subsystems (2)
PATCH 1/1 VLAN does not work with niu driver
From: Joyce Yu <[email protected]>
Date: Wed, 9 Sep 2009 08:43:00 -0700
Subject: [PATCH] VLAN does not work with niu driver
---drivers/net/niu.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
drivers/net/niu.h +0 -0
@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {
#define RCR_PKT_TYPE_UDP 0x2
#define RCR_PKT_TYPE_SCTP 0x3
-#define NIU_RXPULL_MAX ETH_HLEN
+#define NIU_RXPULL_MAX 64
struct rx_pkt_hdr0 {
#if defined(__LITTLE_ENDIAN_BITFIELD)
--
1.6.4
Quoted 23 lines · On Wed, 09 Sep 2009 14:10:48 -0700 Joyce Yu <[email protected]> wrote:
From: Joyce Yu <[email protected]>
Date: Wed, 9 Sep 2009 08:43:00 -0700
Subject: [PATCH] VLAN does not work with niu driverSigned-off-by Joyce Yu <[email protected]>--- drivers/net/niu.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)drivers/net/niu.h +1
-2@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 {#define RCR_PKT_TYPE_UDP 0x2#define RCR_PKT_TYPE_SCTP 0x3 -#define NIU_RXPULL_MAX ETH_HLEN +#define NIU_RXPULL_MAX 64struct rx_pkt_hdr0 {#if defined(__LITTLE_ENDIAN_BITFIELD) --
Quoted 2 lines
1.6.4
Shouldn't the vlan driver being doing pskb_may_pull() or pskb_pull() instead?
David Miller
maintainerFrom: Stephen Hemminger <[email protected]>
Date: Wed, 9 Sep 2009 14:35:14 -0700
Quoted 2 lines
Shouldn't the vlan driver being doing
pskb_may_pull()orpskb_pull()instead?
I thought about it, and my answer is 'probably not'.
Just like for eth_type_trans(), it's pretty reasonable to expect the link level header to be linearized already.
David Miller
maintainerFrom: Joyce Yu <[email protected]>
Date: Wed, 09 Sep 2009 14:10:48 -0700
Quoted 2 lines
drivers/net/niu.h| 2 +-1 files changed, 1 insertions(+), 1 deletions(-)
Can I get a more verbose commit message than this?
Review struct fcram_hash_ipv6 { · line 2704
Quoted 7 lines
(quoted diff) +1
-1@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 { #define RCR_PKT_TYPE_UDP 0x2 #define RCR_PKT_TYPE_SCTP 0x3 -#define NIU_RXPULL_MAX ETH_HLEN +#define NIU_RXPULL_MAX 64
See, that's why I want a detailed commit message, because if you described things more clearly I'd understand why you choose the value '64' as opposed to, say, the size of a VLAN header which to me would be a more appropriate value to use here.
You just seem to be reverting a change I made a while back, and it just so happens to fix your problem. But '64' is too large a value to use here and it will impact performance.
You did check to see if there were any performance regressions resulting from your change, right?
Quoted 12 lines · David Miller
From: Joyce Yu <[email protected]>
Date: Wed, 09 Sep 2009 14:10:48 -0700Quoted 2 lines
drivers/net/niu.h| 2 +-1 files changed, 1 insertions(+), 1 deletions(-)Can I get a more verbose commit message than this?
Quoted 4 lines
(quoted diff) +0
-0@@ -2700,7 +2700,7 @@ struct fcram_hash_ipv6 { #define RCR_PKT_TYPE_UDP 0x2 #define RCR_PKT_TYPE_SCTP 0x3
Quoted 8 lines
Review struct fcram_hash_ipv6 { · line 2704
Quoted 3 lines
(quoted diff) +1
-1-#define NIU_RXPULL_MAX ETH_HLEN +#define NIU_RXPULL_MAX 64See, that's why I want a detailed commit message, because if you described things more clearly I'd understand why you choose the value '64' as opposed to, say, the size of a VLAN header which to me would be a more appropriate value to use here.
Dave,
The frame type in NIU HW is embedded in a HW header, so it is possible to check the HW header and decide whether to pull up ETH_HLEN or VLAN header size of bytes. However, considering the amount of work required to get and examine the HW header (including endianess issues), we thought pulling up 64 bytes by default (as used in cassini.c) would be efficient.
Regards,
Matheos
Quoted 11 lines
You just seem to be reverting a change I made a while back, and it just so happens to fix your problem. But '64' is too large a value to use here and it will impact performance.
You did check to see if there were any performance regressions resulting from your change, right?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
maintainerFrom: Matheos Worku <[email protected]>
Date: Wed, 09 Sep 2009 18:01:23 -0700
Quoted 6 lines
The frame type in NIU HW is embedded in a HW header, so it is possible to check the HW header and decide whether to pull up
ETH_HLENor VLAN header size of bytes. However, considering the amount of work required to get and examine the HW header (including endianess issues), we thought pulling up 64 bytes by default (as used incassini.c) would be efficient.
Well, it was 64 in early versions of the driver, and I decreased it down to ETH_HLEN.
The less the better since for forwarding applications anything past the IPV4 header pulled is going to be a waste of CPU cache lines and thus negatively effect forwarding rates.
That's why I asked if this change was performance regression tested, because I know it's going to slow down forwarding rates for small packets.
Quoted 13 lines · David Miller
From: Matheos Worku <[email protected]>
Date: Wed, 09 Sep 2009 18:01:23 -0700Quoted 6 lines
The frame type in NIU HW is embedded in a HW header, so it is possible to check the HW header and decide whether to pull up
ETH_HLENor VLAN header size of bytes. However, considering the amount of work required to get and examine the HW header (including endianess issues), we thought pulling up 64 bytes by default (as used incassini.c) would be efficient.Well, it was 64 in early versions of the driver, and I decreased it down to
ETH_HLEN.
Quoted 7 lines
The less the better since for forwarding applications anything past the IPV4 header pulled is going to be a waste of CPU cache lines and thus negatively effect forwarding rates.
That's why I asked if this change was performance regression tested, because I know it's going to slow down forwarding rates for small packets.
Dave,
We did throughput testing (netperf) and didn't notice any performance degradation. We haven't done forwarding testing however.
We can work on a version which implements HW header checking and do pullup accordingly.
Regards,
Matheos
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Miller
maintainerFrom: Matheos Worku <[email protected]>
Date: Wed, 09 Sep 2009 18:19:00 -0700
Quoted 2 lines
We can work on a version which implements HW header checking and do pullup accordingly.
I think using a constant based on the vlan header size would be sufficient to fix this.
Quoted 8 lines · David Miller
From: Matheos Worku <[email protected]>
Date: Wed, 09 Sep 2009 18:19:00 -0700Quoted 2 lines
We can work on a version which implements HW header checking and do pullup accordingly.
I think using a constant based on the vlan header size would be sufficient to fix this.
We will have a patch based on vlan header size.
Regards
Matheos
Quoted 4 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines
We did throughput testing (netperf) and didn't notice any performance degradation. We haven't done forwarding testing however.
With my "Mr. Netperf" had on I'll ask if you just measured throughput, or if you also included CPU utilization/service demand?
rick jones