[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090817.184712.180559154.davem@davemloft.net>
Date: Mon, 17 Aug 2009 18:47:12 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: herbert@...dor.apana.org.au
Cc: rusty@...tcorp.com.au, patrick.ohly@...el.com,
netdev@...r.kernel.org, virtualization@...ts.linux-foundation.org,
divy@...lsio.com, rolandd@...co.com, xemul@...nvz.org,
dcbw@...hat.com, libertas-dev@...ts.infradead.org
Subject: Re: [PATCH 1/4] net: skb_orphan on dev_hard_start_xmit
From: Herbert Xu <herbert@...dor.apana.org.au>
Date: Sun, 5 Jul 2009 11:34:08 +0800
> Here's an even crazier idea that doesn't use dummy descriptors.
>
> xmit(skb)
>
> if (TX queue contains no interrupting descriptor &&
> qdisc is empty)
> mark TX descriptor as interrupting
>
> if (TX queue now contains an interrupting descriptor &&
> qdisc len < 2)
> stop queue
>
> if (TX ring full)
> stop queue
>
> clean()
>
> do work
> wake queue as per usual
I'm pretty sure that for normal TCP and UDP workloads, this is just
going to set the interrupt bit on the first packet that gets into the
queue, and then not in the rest.
TCP just loops over packets in the send queue, and at initial state
the qdisc will be empty.
It's very hard to get this to work as well as if we had a real
queue empty interrupt status event.
Even if you get upstream status from the protocols saying "there's
more packets coming" via some flag in the SKB, that only says what one
client feeding the TX ring is about to do.
It says nothing about other threads of control which are about to start
feeding packets to the same device.
--
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