On 09/06/14 00:09, Rick Macklem wrote:
Hans Petter Selesky wrote:
On 09/05/14 23:19, Eric Joyner wrote:
There are some concerns if we use this with devices that ixl
- The maximum fragment size is 16KB-1, which isn't a power of 2.
Multiplying by powers of two are more fast, than non-powers of two.
in this case you would have to use 8KB as a maximum.
Well, I'm no architecture expert, but I really doubt the CPU delay of a
non-power of 2 multiply/divide is significant related to doing smaller
TSO segments. Long ago (as in 1970s) I did work on machines where shifts
for power of 2 multiply/divide was preferable, but these days I doubt it
is going to matter??
- You can't get the maximum TSO size for ixl devices by multiplying
maximum number of fragments by the maximum size.
Instead the number of fragments is AFAIK unlimited, but a segment
span 8 mbufs (including the [up to 3] mbufs containing the header),
maximum TSO size is 256KB.
Maybe that can be a separate parameter?
I see that your patch assumes that a segment can be any-length. That is
not always the case. Remember there are JUMBO mbufs too.
With my patch, the maximum segment size is a separate parameter. The
total number of TSO bytes is then not so useful.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"