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.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
