On Mon, Dec 13, 2010 at 12:16:13PM +0200, Yauheni Kaliuta wrote:
Hi!
/ removing extra Cc /
"eFB" == ext Felipe Balbi writes:
> On Thu, Dec 09, 2010 at 02:17:11PM +0200, Yauheni Kaliuta wrote:
> >Kind of. I'm thinking mostly about generic logic of chained buffer for
> >request. If there is chained DMA, it can be used then, or it can be
> >emulated in SW, it's possible to use DMA to submit only parts, PIO for
> >others, it's possible to even make a flat buffer inside ...
> But only with chained DMA that'll pose benefits, no ? Otherwise you'll
> have to reprogram the DMA, so CPU intervention will still be needed.
Yes, but I expect that the overhead will be less, then the extra copiing
of all data before to the one req->buf. No?
Yeah but my point was that you would have a dma pool (a big one,
physically contiguous) then you allocate N skbuffs from that pool (I
know that's not possible now), then, when pool is full of data, you kick
DMA and make req->buf point to the pool req->length should be equal to
DMA_POOL_SIZE.
No copies needed, if what I'm saying can be done. I'm not sure :-p
> >About network layer I'm thinking first of allocating of skbs with respect
> >of bottom layer. Like we have an api to gadget driver to allocate usb
> >request, network layer may have an api to network driver (and thats usbnet
> >for us) to prepare skb how it's better for it. You are talking already more
> >closer to the implementation details if I understand you right.
> >
> >Do my words sound logical somehow?
> Yes it does, but skbuffs are not re-usable, with the code as is, so
> either your gadget driver or usbnet, will have to reallocate skbuffs
> anyway.
That's mostly about frame grouping? Agree, that's the second problem.
Not frame grouping, it's about how our socket layer is written. We can't
allocate skbuff->buf ourselves and we can't re-use the same skbuff for
another request. We always have to allocate, copy data if TX, send,
free.
--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
