James Carlson wrote:
> gopanapalli pradeep writes:
>
>> Hi ,
>> My hardware has a limitation of accepting only 31 Tx fragments ,while iam
>> running heavy network traffic iam seeing packets with more than 60
>> fragments(especially with jumbo packets).Though iam managing by doing a copy
>> of remaining fragments , i wanted to know is there any way to limit number
>> of fragments .
>>
>
> No, there's no way to do that. If you can't fix the flaw in the
> hardware, I think you'll need to handle this issue in your driver by
> doing either msgpullup(9F) calls or custom-written code to coalesce
> buffers.
>
I do want to point out something as well. If you have a bajillion
little fragments, it is usually *faster* to go ahead and just copy
them/coalesce them into a single premapped buffer rather than using
dma/dvma tricks to try to map them in place. On modern machines, bcopy
is quite fast, and the pain associated with setting up DMA/DVMA mappings
can be somewhat high -- even using the various "tricks" to get optimum
performance. A lot of those tricks are only available on the receive
path in any case.
The threshold for when to copy versus when to map directly varies, and
is the topic of some debate, but I've not seen any machine manufactured
in the last decade where bcopy performed worse for packets/fragments of
512 bytes or less. I suspect on modern hardware the threshold is
somewhere between 2K and 4K, though specific measurements would be required.
It used to be the case that packets made up of more than a few fragments
were "uncommon". (It used to be most common that you'd have either 1 or
2 fragments. IPsec and similar technologies have probably changed that
somewhat, but I'd guess that packets with more than 5 fragments should
be *quite* rare. If they're not, you might want to try to figure out
why they are showing up so heavily in your particular application.)
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
