Re: [RFC PATCH] sched: only dequeue if packet can be queued to hardware queue.

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Jarek Poplawski <jarkao2@...>
Cc: Alexander Duyck <alexander.h.duyck@...>, <netdev@...>, <herbert@...>, <davem@...>, <kaber@...>
Date: Thursday, September 18, 2008 - 9:11 pm

On Thu, Sep 18, 2008 at 12:44 PM, Jarek Poplawski <jarkao2@gmail.com> wrote:

The thing is this was just meant to be a proof of concept for the most
part so I was doing a lot of cut and paste coding, and as a result the
size increased by a good amount.  I admit this could be cleaned up a
lot I just wanted to verify some things.

Also my ultimate goal wasn't to kill requeue completely as you can't
do that since in the case of TSO/GSO you will end up with SKBs which
require multiple transmit descriptors and therefore you will always
need an option to requeue.  The advantage with this approach is that
you don't incur the CPU cost, which is a significant savings when you
compare the requeue approach which was generating 13% cpu to the smart
dequeue which was only using 3%.


I did run checkpatch on this.  Most of the errors are inherited from
the cut and paste and I didn't want to take the time to completely
rewrite the core qdisc functionality.  Other than those errors I
believe some were whitespace complaints as I was using tabs to the
start of my functions and then spaces to indent my function parameters
in the case of having to wrap for long lines.


Once again if you have a suggestion on approach feel free to modify
the patch and see how it works for you.  My only concern is that there
are several qdiscs which won't give you the same packet twice and so
you don't know what is going to pop out until you go in and check.


Right, but then we are getting back to the queue/requeue stuff.  If
you want feel free to make use of my patch to generate your own that
uses that approach.  I just don't like changing things unless I
absolutely have to and all I did is essentially tear apart
__skb_dequeue and place the bits inline with my testing for
netif_tx_subqueue_stopped.


For the most part I would agree with you, but for now I was only using
the flag as a part of the smart_dequeue process to flag the upper
queues so I didn't give it much thought.  It is yet another thing I
probably should have cleaned up but didn't get around to since this
was mostly proof of concept.


Actually I could probably replace most of the skb_peek stuff with
calls to __qdisc_smart_dequeue instead and then just check for the
flag on fail.


I probably won't be able to contribute to this for at least the next
two weeks since I am going to be out for vacation from Saturday until
the start of October.

In the meantime I also just threw a couple of patches out which may
help anyone who is trying to test this stuff.  Turns out if you try to
do a netperf UDP_STREAM test on a multiqueue aware system with 2.6.27
you get horrible performance on the receive side.  The root cause
appears to be that simple_tx_hash was doing a hash on fragmented
packets and as a result placing packets in psuedo random queues which
caused issues with packet ordering.

Thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
RE: [RFC PATCH] sched: only dequeue if packet can be queued ..., Duyck, Alexander H, (Fri Sep 19, 12:26 pm)
RE: [RFC PATCH] sched: only dequeue if packet can be queued ..., Duyck, Alexander H, (Fri Sep 19, 2:01 pm)
RE: [RFC PATCH] sched: only dequeue if packet can be queued ..., Duyck, Alexander H, (Fri Sep 19, 5:43 pm)
Re: [RFC PATCH] sched: only dequeue if packet can be queued ..., Alexander Duyck, (Thu Sep 18, 9:11 pm)
[PATCH take2] pkt_sched: Fix TX state checking in qdisc_run(), Jarek Poplawski, (Fri Sep 19, 10:44 am)
[PATCH] pkt_sched: Fix TX state checking in qdisc_run(), Jarek Poplawski, (Fri Sep 19, 9:07 am)