Thread (53 messages) 53 messages, 14 authors, 2013-04-09

RE: [Xen-devel] [PATCH 5/6] xen-netback: coalesce slots before copying

From: James Harper <hidden>
Date: 2013-03-26 11:29:36

quoted
As stated previously, I've observed windows issuing staggering numbers of
buffers to NDIS miniport drivers, so you will need to coalesce in a windows
driver anyway. I'm not sure what the break even point is but I think it's safe
to say that in the choice between using 1000 (worst case) ring slots (with
the
resulting mapping overheads) and coalescing in the frontend, coalescing is
going to be the better option.
Oh quite, if the backend is mapping and not copying then coalescing in the
frontend is the right way to go. I guess coalescing once the frag count
reaches a full ring count is probably necessary (since we can't push a partial
packet) but it would be nice not to have to do it if the backend is going to
copy anyway.
For a 9k packet with 100 frags (not a common case, but an example), what is the cost of mapping those 100 frags into the backend vs coalescing to three pages in the frontend and mapping those?

I may be misremembering but wasn't there a patch floating around for persistent mapping to avoid some of this overhead? (not applicable here but I thought it meant that the cost wasn't insignificant)

James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help