NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/46961: Please support BCM57762 Ethernet arapter(Apple'sThunderbolt Ethernet Adapter)



The following reply was made to PR kern/46961; it has been noted by GNATS.

From: David Laight <david%l8s.co.uk@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/46961: Please support BCM57762 Ethernet 
arapter(Apple'sThunderbolt Ethernet Adapter)
Date: Mon, 17 Sep 2012 07:57:39 +0100

 On Mon, Sep 17, 2012 at 04:45:02AM +0000, Izumi Tsutsui wrote:
 > The following reply was made to PR kern/46961; it has been noted by GNATS.
 > 
 > From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
 > To: ryo_on%yk.rim.or.jp@localhost
 > Cc: gnats-bugs%NetBSD.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
 > Subject: Re: kern/46961: Please support BCM57762 Ethernet 
 > arapter(Apple'sThunderbolt
 >       Ethernet Adapter)
 > Date: Mon, 17 Sep 2012 13:41:25 +0900
 > 
 >  > http://www.netbsd.org/~ryoon/120916b-bcm57762.diff
 >   :
 >  > I have defined ETHER_VLAN_MAX_LEN in the suggested place of if_bgereg.h.
 >  > It works.
 >  
 >  I notice original FreeBSD's bge driver uses BGE_MAX_FRAMELEN for
 >  BGE_RX_STD_RCB_MAXLEN_FLAGS register, and we also use it in
 >  older !BGE_IS_5705_PLUS(sc) case.
 >  
 >  The value is used to specify "Maximum Ethernet Frame Length"
 >  for RX descriptors, so 1536 bytes should also work and using it
 >  as a bge's magic number would be better to avoid divergence
 >  from other OSes.
 >  
 >  In our if_bgereg.h, BGE_MAX_FRAMELEN is defined as following:
 >  
 >  > #define BGE_MAX_FRAMELEN  (ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN)
 >  
 >  but this seems wrong because ETHER_MAX_LEN already includes header
 >  and CRC length, and the original FreeBSD's bge just defines it as "1536"
 >  (though ETHER_MAX_LEN + ETHER_HDR_LEN + ETHER_CRC_LEN is also 1536),
 >  so I'll change BGE_MAX_FRAMELEN definition.
 
 There are all sorts of reasons why an rx buffer size of 1536 is a good idea.
 Mostly because it is a nice round number!
 It might even be that the register it gets written to has non-writeable
 low bits.
 Allowing 'slightly overlong' packets is useful for certain protocols,
 I'm sure I remember something else, as well as VLAN, extending the
 maximum length.
 
 Generating 1536 as in BGE_MAX_FRAMELEN above is rather bogus though.
 I also don't really remember DIX meaning anything in particular.
 
        David
 
 -- 
 David Laight: david%l8s.co.uk@localhost
 


Home | Main Index | Thread Index | Old Index