Call for stge(4) testers
Pyun YongHyeon
pyunyh at gmail.com
Fri Jul 14 04:38:21 UTC 2006
On Thu, Jul 13, 2006 at 05:20:09PM +0000, Bill Paul wrote:
[...]
>
> > However in the long run it did work
> > after about a minuate without any action from user.
>
> Hm. Well, here's the thing: ethernet controller's can't tell time. I
> think it's less of an issue of how much time it takes before the NIC
> starts sending jumbo frames correctly and more of an issue of how
> many failed transmission attempts occur before one succeeds. Did you
> count the number of bad transmissions that occur before the chip
> starts working? Was it always the same number? Did you instrument
> the interrupt handler to see if TX completion events are actually
> occuring for each transmission? (Just because you made it into
No I didn't. Because it now works as expected I didn't want to try
again. Well, experimenting with jumbo frame is time consuming task
and I'm running out all my spare time.
> stge_start() and queued the packet up doesn't mean transmission
> completed?)
>
>
[...]
> > That's exactly what I did it on my tests. From your detailed
> > explanation on jumbo frame internals and guide I've reread source
> > code related to jumbo frame and managed to find a bug in my code.
> > It was my programming error in selecting an MTU from ioctl handler.
> > However I don't understand how the hardware can send/receive larger
> > MTUs than 9022.
>
> What is it about this that you don't you understand, exactly? Is it
> something about this particular chip, or about being able to have
> frames larger than 9022 bytes in general? (Technically jumbo frames
> can be up to 16K in length, but by convention most people use 9000
> bytes.) Mind you, this is one chip I've never gotten around to writing
> a driver for myself, so I'm sure I'm missing something.
>
I meant I wondered how it could send/receive a larger sized frame than
9022 bytes which is the max. supported size on TC9021.
> > If you program the hardware to receive 10K it
> > eventually work in a one or two minute.
>
> Like I said, it's probably a question of some sequence of events
> occuring before it starts to work, not the passage of a certain amount
> of time. It may be that you have to disable and re-enable the TX and/or
> RX dma engines before switching to the larger frame size. Also, verify
> that you properly initialize all of the fields in the TX descriptors
> on each transmission so you're not keeping stale bits set from
> previous transmissions. There's also a slight chance this is a stack
> bug, not a driver/chip bug. What happens if you do:
>
> # ifconfig stge0 mtu 9000
> # ifconfig stge0 down
> # ifconfig stge0 up
>
> Does it still take a minute for transmissions to succeed?
>
No, it now works as expected in all situations. Of course, there is
no need to bring the interface down/up after changing an MTU.
Thanks a lot.
--
Regards,
Pyun YongHyeon
More information about the freebsd-current
mailing list