Subject: Re: nfe(4) hardware checksum support
To: None <cube@cubidou.net>
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
List: tech-kern
Date: 02/04/2007 14:40:30
cube@cubidou.net wrote:
> RX is definitely the problem. When I experience such stalls (which seem
> to happen as soon as a high packet rate comes in), I can still see
> packets coming out through nfe. I don't remember if I checked with
> tcpdump, but pinging the broadcast address does blink the whole switch,
> so I'm quite positive.
If it's caused by some race condition, how about the attached one?
BTW, which is your port, i386 or amd64?
With a quick glance there is not any improper reordering around
descriptor access even without volatile on i386, but I'm not sure.
---
Izumi Tsutsui
Index: if_nfereg.h
===================================================================
RCS file: /cvsroot/src/sys/dev/pci/if_nfereg.h,v
retrieving revision 1.3
diff -u -r1.3 if_nfereg.h
--- if_nfereg.h 9 Jan 2007 10:29:27 -0000 1.3
+++ if_nfereg.h 4 Feb 2007 05:01:10 -0000
@@ -144,9 +147,9 @@
/* Rx/Tx descriptor */
struct nfe_desc32 {
- uint32_t physaddr;
- uint16_t length;
- uint16_t flags;
+ volatile uint32_t physaddr;
+ volatile uint16_t length;
+ volatile uint16_t flags;
#define NFE_RX_FIXME_V1 0x6004
#define NFE_RX_VALID_V1 (1 << 0)
#define NFE_TX_ERROR_V1 0x7808
@@ -155,12 +158,12 @@
/* V2 Rx/Tx descriptor */
struct nfe_desc64 {
- uint32_t physaddr[2];
- uint32_t vtag;
+ volatile uint32_t physaddr[2];
+ volatile uint32_t vtag;
#define NFE_RX_VTAG (1 << 16)
#define NFE_TX_VTAG (1 << 18)
- uint16_t length;
- uint16_t flags;
+ volatile uint16_t length;
+ volatile uint16_t flags;
#define NFE_RX_FIXME_V2 0x4300
#define NFE_RX_VALID_V2 (1 << 13)
#define NFE_RX_IP_CSUMOK (1 << 12)