Hans Petter Selasky wrote:
> I'm asking for some input on the attached m_dup() patch, so that
> existing functionality or dependencies are not broken. The background
> for the change is to allow m_dup() to defrag long mbuf chains that
> doesn't fit into a specific hardware's scatter gather entries,
> when doing TSO.
> In my case the HW limit is 16 entries of length 4K for doing a
> TSO packet. Currently m_dup() is at best producing 32 entries of each
> for a 64Kbytes TSO packet.
> By allowing m_dup() to get JUMBO clusters when allocating mbufs, we
> avoid creating a new function, specific to the hardware, to defrag
> rare-occurring very long mbuf chains into a mbuf chain below 16
> Any comments?
1 - If you are using NFS with the default (64K) I/O size, then long
mbuf chains of 35 entries aren't rare. They happen on every read
2 - When I changed NFS to use pagesize clusters for reads/writes I was
able to get the system into a state where threads were persistently
stuck on "btalloc". If I understand this correctly, the system was
not able to allocate boundary tags because the kernel address space
had been fragmented too much.
--> As such, I never committed this patch to head and would caution
against using pagesize clusters.
I do not have a better solution at this point, but I do have an untested
patch (I need to get access to some TSO enabled hardware to test it) that
adds if_hw_tsomaxseg, which is a count of the maximum number of transmit
segments (mbufs in chain) that a network device driver supports.
I think that having the driver set if_hw_tsomaxseg == 16 is preferable to
doing a copy of the data to pagesize clusters. (I'd also say that hardware
that supports only 16 transmit segments for a TSO segment is not a good piece
of hardware for FreeBSD.)
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"