Garrett D'Amore wrote:
Oliver Yang wrote:
Dan Mick wrote:
Oliver Yang wrote:
Garrett D'Amore wrote:
Oliver Yang wrote:
Hi Guys,
If I use kmem_alloc to alloc a buffer less than 4K, can it ensure
that buffer doesn't cross the page boundary(4k on x86)?
It probably won't cross a page boundary, but the DDI does not
guarantee this.
If you want to provide guarantees like this, use
ddi_dma_mem_alloc() with attributes that specify that page
boundaries should not be crossed.
Yes, I knew. On the man page of kmem_alloc, it just ensures memory
is at least double-word aligned, and no other guarantees.
But I really want to know whether current implementation of
kmem_alloc or slab can guarantees this, if the request alloc size
is less than 4k.
Since not only one guys told me, that is true.
1) so read the source.
2) why do you "really want" to know this? knowing it is useless, as
it is *not guaranteed*, which means it can change at any time.
Yes, I understand that we should not let our code has this kind of
wrong assumption.
A NIC driver who supports LSO will run into hang state if the TCP
header cross the 4k page boundary.
Although the TCP packet is NOT actually allocated by the kmem_alloc,
but it comes from esballoc which should be similar with kmem_alloc.
All bets off with esballoc, unless you use it with kmem_alloc to
allocate your data area (in which case you really *should* use
ddi_dma_mem_alloc().)
On most regular NIC hardwares, this will not cause the issue. But in
this LSO special cases, hardware doesn't allow the tcp header cross
the multiple DMA cookies.
I just want to know whether this issue is only happened in that TPC
packet is large than 4K case, or it happend for all the cases.
With a large allocation (larger than 4K), your boundaries can occur at
unpredictable locations. It sounds to me like this NIC driver needs
to bcopy the header into a preallocated (ddi_dma_mem_alloc!)
contiguous region, and use cookies for the payload.
Also, with LSO, the data is coming from *upstream*, so esballoc might
not have been used (probably won't have been!), and there are *no*
guarantees about how the IP stack formulates its mblks.
This is an old issue which has been addressed with the solution you
mentioned above, but I'm still wondering whether we could address this
issue by improving the mblk cache.
These days I also encountered another issue which is similar with this
issue, and I just discussed with other guys who said that slab can
ensure the object size less than one page can not cross the page boundary.
Anyway, thank for your information.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
