Date: Thu, 14 Apr 2005 20:09:35 -0700 From: John-Mark Gurney <gurney_j@resnet.uoregon.edu> To: Pyun YongHyeon <yongari@rndsoft.co.kr> Cc: freebsd-sparc64@freebsd.org Subject: Re: em(4) patch Message-ID: <20050415030935.GQ56487@funkthat.com> In-Reply-To: <20050415023902.GC7393@michelle.rndsoft.co.kr> References: <20050414092608.GB2855@michelle.rndsoft.co.kr> <20050414192749.GO56487@funkthat.com> <20050415023902.GC7393@michelle.rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun YongHyeon wrote this message on Fri, Apr 15, 2005 at 11:39 +0900: > On Thu, Apr 14, 2005 at 12:27:49PM -0700, John-Mark Gurney wrote: > > > > . always honor IFF_OACTIVE flag > > > > I made this mistake before myself.. Make sure you read the comment > > describing OACTIVE.. you only set OACTIVE when the TX queue is full, > > and clear it when it is not full.. not always set it when the board > > is transmitting: > > define IFF_OACTIVE 0x400 /* tx hardware queue is full */ > > > > Do you mean IFF_OACTIVE should be set regardless of TX queue state > when h/w is transmitting frames? Would you elaborate on an IFF_OACTIVE? IFF_OACTIVE should be set when the hardward cannot queue anymore packets, and should be cleared when the hardware can accept additional packets.. It basicly controls calling an interface's if_start routine.. If IFF_OACTIVE is set, then it is assumed no additional packets can be processed, and if_start will not be called when a packet is queued for the interface... If you look at net/if_var.h for the define IFQ_HANDOFF_ADJ, you'll see where it is tested... > > > . TX/RX descriptor alignment is 16 not PAGE_SIZE > > > . TX/RX descriptor length should be multiple of 128 not 4096. > > > > You should probably use a define for this... > > > > Yes. But AFAIK if_em_hw.h has no defined constants for these purposes. Then add them.. :) > There are another hardcoded constants for processing 64bit IO BAR. I > belive these constants should go pcireg.h. Hmmm. which ones are these? > > > I have tested 82545GM chipset based card on Ultra60(SMP). VLAN and > > > POLLING were not tested at all so it may have bugs. JUMBO frame support > > > needs more coding and cleanups since sparc64 does not allow non-aligned > > > memory access. So don't try to use JUMBO frame at this time. > > > If you want to test em(4) on SMP with ofw_console you need additional > > > patch. Alternatively you can use sc(4) or serial console. > > > I'd like to hear success/failure. > > > > I think you should put back the while(!IFQ_DRV_IS_EMPTY, loop.. It > > prevents an unnessary lock/unlock if both queues are empty... > > > > Yes, you're right. > > > Also, I have work in progress to make non-aligned packets better... > > I committed part of it as the m_copyup change... On a -current, you > > should just be able to apply the following change: > > http://perforce.freebsd.org/fileDiffView.cgi?FSPC=//depot/user/jmg/arm/src/sys/netinet/ip%5finput.c&REV=3&ACT=edit > > > > This looks promising. Some miserable hardwares that use sf(4)/rl(4) > driver could take advatnage of it. BTW what is IP_HDR_ALIGNED_P macro? Look at: http://perforce.freebsd.org/fileDiffView.cgi?FSPC=//depot/user/jmg/arm/src/sys/netinet/ip%5fvar.h&REV=2&ACT=edit and __NO_STRICT_ALIGNMENT should be defined somewhere for i386 and amd64.. I sent an email to bde asking about where to define this, but he didn't respond... > > I'll try the patch when I get home... > > Thanks. np... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050415030935.GQ56487>