On 8/8/06, David (Controller AE) Christensen <[EMAIL PROTECTED]> wrote:
>
> Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly
> fragmented packets under heavy loads. To simulate the situation
> you can use m_fragment(9) to fragment the frame in bce_tx_encap().
> With m_fragment(9), "ping -f -s 65507 x.x.x.x" may trigger it.
>
I didn't know about m_fragment before. I'll write a note to myself
and look at how to add it to the debug path for a future driver
revision.
> Btw, I've never seen this small number of Tx DMA segments support(
> BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation?
>
The real value for BCE_MAX_SEGMENTS should be 16, not 8. I chose 8 as a
reasonable value to start with. If the number of fragments exceeds 16
then we would expect to see performance drop and it is probably faster
to
have the OS defragment the packet rather than try to perform so many
DMAs.
What I don't understand is why the driver stays locked up after it
gets into this mode. I guess that's a separate issue from the low max
segments which is triggering it in the first place?
-scott
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
