Hi Roland, Roland Dreier <[EMAIL PROTECTED]> wrote on 05/11/2007 01:51:50 AM:
> This is pretty interesting to me for IP-over-InfiniBand, for a couple > of reasons. First of all, I can push multiple send requests to the > underlying adapter in one go, which saves taking and dropping the same > lock and also probably allows fewer MMIO writes for doorbells. > > However the second reason this is useful is actually more > interesting. Right now we request a send completion interrupt for > every packet we send because most current IB adapters don't really > have very good interrupt mitigation features. If we don't signal a > send completion for every packet, then we might run into a situation > where we don't get a completion for the last packet that gets sent and > end up stalling the interface because the stack never gives us another > packet to send. However, if I have a whole queue of packets passed to > my xmit routine, then I only have to request a completion for the last > packet in the list, which could potentially cut down on interrupts and > completion processing a lot. Sounds a good idea. I had a question on error handling. What happens if the driver asynchronously returns an error for this WR (single WR containing multiple skbs) ? Does it mean all the skbs failed to be sent ? Requeuing all of them is a bad idea since it leads to infinitely doing the same thing, so should every skb be free'd ? Isn't that harsh (if first skb is bad and others are fine) and how do we avoid that ? Infact we don't know which skb was transmitted and which failed. If we requeue skbs, there will also be out-of-order skbs as the callback is asynchronous. Thanks, - KK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
