Nicolas Droux writes:

Thank you for the very helpful reply.

 > Andrew Gallatin wrote:
 > 
 > > 
 > > 3.7.2 mi_sdu_min
 > > 
 > > "This should be set to the minimum payload size that can be conveyed by
 > > the media(5).
 > > 
 > > 5: For DL_ETHER devices supporting jumbo frames this should still be
 > > set to ETHERMTU."
 > > 
 > > I assume this is a typo, and this should be something like 60?  Or (60
 > > - 14) ?  It looks like bge sets it to zero.
 > 
 > The footnote shouldn't be there. Note that the specified length is the 
 > payload length which does not include the MAC header.

Let me rephrase the question.  If the minumum frame size for ethernet
is 60 bytes, and our device does not pad frames to 60 bytes by itself,
will filling in 60 cause the stack to do the padding for me?  Or will
I still need to watch for runts and pad them myself in the driver?


<....>

 > As of Solaris Nevada build 30, we provided the softrings mechanism which 
 > is implemented at the Nemo layer, and optionally performs load spreading 
 > to multiple threads in software, when the NIC does not support multiple 
 > hardware rings. We need to write a full description of this mechanism, 
 > but if you can find the implementation at:
 > 
 > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/io/dls/dls_soft_ring.c

Cool.  From the comments in that file, it sounds like this also
preserves locality.  Is this slated for a merge into a shipping
Solaris10 version?  Eg, I know some version of Nemo is in 10U1.  Are
softrings in 10U1?

 > > 4.1.6 mac_tx_update
<....>
 > > At this point, it is possible that m_tx() may never be called
 > > again, if the interrupt cleaned all transmitted frames.
 > > Please tell me this is not possible.
 > 
 > We're handling this case now with dld, your driver shouldn't have to 
 > worry about that. All your driver has to do is return the unsent packets 
 > from the transmit entry point, and invoke the mac_tx_update() routine 
 > when it has available transmit descriptors.

OK, it is magic then.  As long as it works and I don't need to be
paranoid about it. :)

One thing I omitted yesterday was that I really like how m_tx()
handles chained packets.  Depending on how far up the stack the chain
can be built, it sounds almost like a poor man's TSO.  it will be
interesting to compare our TSO CPU utilization on linux with Nemo on
Solaris..

Thanks again,

Drew

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to