From: Herbert Xu
Date: Wed, 19 Aug 2009 13:19:26 +1000
> I'm in the process of repeating the same experiment with cxgb3
> which hopefully should let me turn interrupts off on descriptors
> while still reporting completion status.
Ok, I look forward to seeing your work however it turns out.
Once
On Mon, Aug 17, 2009 at 06:47:12PM -0700, David Miller wrote:
>
> 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 a
From: Herbert Xu
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 qu
On Sun, Jul 05, 2009 at 11:26:58AM +0800, Herbert Xu wrote:
>
> Here's a another crazy idea:
>
> Let's use dummy TX descriptors to generate an interrupt, either
> with or without transmitting an actual packet on the wire depending
> on the NIC.
Here's an even crazier idea that doesn't use dummy
On Sat, Jul 04, 2009 at 05:09:10PM +0800, Herbert Xu wrote:
>
> One potential problem is if the socket is constantly running
> close to capacity, but that should only happen if the device
> TX queue is also close to capacity which means that the qdisc
> queue should be non-empty.
Here's a another
On Sat, Jul 04, 2009 at 03:42:45PM +0800, Herbert Xu wrote:
>
> Here's an idea: We let the sender decide whether we need to enable
> notification. This decision would be carried as a flag in the skb.
> For example, UDP would set this flag when its socket buffer is close
> to capacity. Routing wo
On Fri, Jul 03, 2009 at 08:13:47PM -0700, David Miller wrote:
>
> NIU
>
> I basically can't defer interrupts because the chip supports
> per-TX-desc interrupt indications but it lacks an "all TX queue sent"
> event. So if, say, tell it to interrupt every 1/4 of the TX queue
> then up to 1/4 of th
From: Herbert Xu
Date: Sat, 4 Jul 2009 11:08:30 +0800
> On Fri, Jul 03, 2009 at 08:02:54PM -0700, David Miller wrote:
>>
>> In particular the case of handling a device without usable TX
>> completion event indications is still quite troublesome.
> e
> Which particular devices do you have in mind?
On Fri, Jul 03, 2009 at 08:02:54PM -0700, David Miller wrote:
>
> In particular the case of handling a device without usable TX
> completion event indications is still quite troublesome.
Which particular devices do you have in mind?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: He
From: Herbert Xu
Date: Fri, 3 Jul 2009 15:55:30 +0800
> Calling skb_orphan like this should be forbidden. Apart from the
> problems already raised, it is a sign that the driver is trying to
> paper over a more serious issue of not cleaning up skb's timely.
>
> Yes skb_orphan will work for the c
David Miller wrote:
>
>> I think I'll do this in the driver for now, and let's revisit doing it
>> generically later?
>
> That might be the best course of action for the time being.
> This whole area is a rat's nest.
Calling skb_orphan like this should be forbidden. Apart from the
problems alr
From: Eric Dumazet
Date: Thu, 04 Jun 2009 06:54:24 +0200
> We also can avoid the sock_put()/sock_hold() pair for each tx packet,
> to only touch sk_wmem_alloc (with appropriate atomic_sub_return() in
> sock_wfree()
> and atomic_dec_test in sk_free
>
> We could initialize sk->sk_wmem_alloc to on
David Miller a écrit :
> From: Rusty Russell
> Date: Thu, 4 Jun 2009 13:24:57 +0930
>
>> On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
>>> Also, taking a reference on socket for each xmit packet in flight is very
>>> expensive, since it slows down receiver in __udp4_lib_lookup(). Several
>>>
From: Rusty Russell
Date: Thu, 4 Jun 2009 13:24:57 +0930
> On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
>> Also, taking a reference on socket for each xmit packet in flight is very
>> expensive, since it slows down receiver in __udp4_lib_lookup(). Several
>> cpus are fighting for sk->refcnt
On Thu, 4 Jun 2009 06:32:53 am Eric Dumazet wrote:
> Rusty Russell a écrit :
> > On Sat, 30 May 2009 12:41:00 am Eric Dumazet wrote:
> >> For TCP, I agree your patch is a huge benefit, since its paced by remote
> >> ACKS and window control
> >
> > I doubt that. There'll be some cache friendliness,
Rusty Russell a écrit :
> On Sat, 30 May 2009 12:41:00 am Eric Dumazet wrote:
>> Rusty Russell a écrit :
>>> DaveM points out that there are advantages to doing it generally (it's
>>> more likely to be on same CPU than after xmit), and I couldn't find
>>> any new starvation issues in simple benchma
From: Rusty Russell
Date: Tue, 2 Jun 2009 23:38:29 +0930
> On Tue, 2 Jun 2009 04:55:53 pm David Miller wrote:
>> From: Patrick Ohly
>> Date: Mon, 01 Jun 2009 21:47:22 +0200
>>
>> > On Fri, 2009-05-29 at 23:44 +0930, Rusty Russell wrote:
>> >> This patch adds skb_orphan to the start of dev_hard_s
On Fri, 2009-05-29 at 23:44 +0930, Rusty Russell wrote:
> This patch adds skb_orphan to the start of dev_hard_start_xmit(): it
> can be premature in the NETDEV_TX_BUSY case, but that's uncommon.
Would it be possible to make the new skb_orphan() at the start of
dev_hard_start_xmit() conditionally s
On Tue, 2 Jun 2009 04:55:53 pm David Miller wrote:
> From: Patrick Ohly
> Date: Mon, 01 Jun 2009 21:47:22 +0200
>
> > On Fri, 2009-05-29 at 23:44 +0930, Rusty Russell wrote:
> >> This patch adds skb_orphan to the start of dev_hard_start_xmit(): it
> >> can be premature in the NETDEV_TX_BUSY case,
From: Patrick Ohly
Date: Mon, 01 Jun 2009 21:47:22 +0200
> On Fri, 2009-05-29 at 23:44 +0930, Rusty Russell wrote:
>> This patch adds skb_orphan to the start of dev_hard_start_xmit(): it
>> can be premature in the NETDEV_TX_BUSY case, but that's uncommon.
>
> Would it be possible to make the new
On Sat, 30 May 2009 12:41:00 am Eric Dumazet wrote:
> Rusty Russell a écrit :
> > DaveM points out that there are advantages to doing it generally (it's
> > more likely to be on same CPU than after xmit), and I couldn't find
> > any new starvation issues in simple benchmarking here.
>
> If really n
Rusty Russell a écrit :
> Various drivers do skb_orphan() because they do not free transmitted
> skbs in a timely manner (causing apps which hit their socket limits to
> stall, socket close to hang, etc.).
>
> DaveM points out that there are advantages to doing it generally (it's
> more likely to
Various drivers do skb_orphan() because they do not free transmitted
skbs in a timely manner (causing apps which hit their socket limits to
stall, socket close to hang, etc.).
DaveM points out that there are advantages to doing it generally (it's
more likely to be on same CPU than after xmit), and
23 matches
Mail list logo
