Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 05/11/2007 03:02:02 PM:
> On Fri, May 11, 2007 at 02:48:14PM +0530, Krishna Kumar2 ([EMAIL PROTECTED]) wrote: > > > And what if you have thousand(s) of packets queued and first one has > > > failed, requeing all the rest one-by-one is not a solution. If it is > > > being done under heavy lock (with disabled irqs especially) it becomes a > > > disaster. > > > > If first one failed for other reasons from described below, it is freed up > > and the next one attempted. There are three cases where we cannot continue > > : > > no slots, device blocked, no lock. > > > Why stack should ever know what hardware is being used? > If you are going to break things, break it with scary sound :) Actually it could just be an API exported by drivers which implement this new xmit API. > Design new interface, where driver has access to the queue (say only > using one helper dequeue_first_packet()), stack can only queue packets > to the tail, driver can also stop that by setting a bit (which was there > likely before we had knew word Linux). > > That is all, driver does not access qdisk, it only gets the first skb. > Transmit function is completely lockless (until something is shared with > receive path/interrupts, but it is private driver's part), stack will > not be changed at all (except new helper to dequeue first packet from > the qdisk, actually it is already there, it just needs to be exported), > driver's xit function sets a flag that there are packets (or it can be > even empty, since packet's presense can be detected via the same qdisk > interface). You read qdisk len, setup several descriptors in one go, > dequeue set of skbs and commit them. If something has failed, it is not > requeued, but resent (or even dropped after fair amount of attempts). > No locks, no requeues? Seems simple imho. I will analyze this in more detail when I return (leaving just now, so got really no time). The only issue that I see quickly is "No locks", since to get things off the queue you need to hold the queue_lock. 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
