[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070510.144007.62663063.davem@davemloft.net>
Date: Thu, 10 May 2007 14:40:07 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: dlstevens@...ibm.com
Cc: rick.jones2@...com, johnpol@....mipt.ru, krkumar2@...ibm.com,
netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: [RFC] New driver API to speed up small packets xmits
From: David Stevens <dlstevens@...ibm.com>
Date: Thu, 10 May 2007 14:27:56 -0700
> The word "small" is coming up a lot in this discussion, and
> I think packet size really has nothing to do with it. Multiple
> streams generating packets of any size would benefit; the
> key ingredient is a queue length greater than 1.
>
> I think the intent is to remove queue lock cycles by taking
> the whole list (at least up to the count of free ring buffers)
> when the queue is greater than one packet, thus effectively
> removing the lock expense for n-1 packets.
Right.
But I think it's critical to do two things:
1) Do this when netif_wake_queue() is triggers and thus the
TX is locked already.
2) Have some way for the driver to say how many free TX slots
there are in order to minimize if not eliminate requeueing
during this batching thing.
If you drop the TX lock, the number of free slots can change
as another cpu gets in there queuing packets.
I know there are some hardware workarounds that require using
more TX ring buffer slots and are usually necessary, which
makes %100 accurate indication of free slots not possible.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists