Hi David,
You wrote:
> 2) We can't turn sk_forward_alloc easily into an atomic_t. The
>masking operation in __sk_stream_mem_reclaim() does not translate
>readily into an atomic_t op:
>
> sk->sk_forward_alloc &= SK_STREAM_MEM_QUANTUM - 1;
>
>That line has always driven
On Mon, 17 Apr 2006, Herbert Xu wrote:
>
> On Mon, Apr 17, 2006 at 02:09:43PM -0700, Jesse Brandeburg wrote:
> >
> > we explicitly enabled TSO before performing the test.
> > attached bz2 due to size:
>
> Thanks a lot. Are those promiscuous mode messages caused by tcpdump?
> If so could you t
On Mon, Apr 17, 2006 at 02:09:43PM -0700, Jesse Brandeburg wrote:
>
> we explicitly enabled TSO before performing the test.
> attached bz2 due to size:
Thanks a lot. Are those promiscuous mode messages caused by tcpdump?
If so could you try it without doing a tcpdump or any other af_packet
appli
On Mon, 17 Apr 2006, David S. Miller wrote:
>
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Mon, 17 Apr 2006 16:17:00 +1000
>
> > On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> > > So it nearly has to be a send side issue that can only trigger with
> > > TSO enabled, and my
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Mon, 17 Apr 2006 16:17:00 +1000
> On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> > So it nearly has to be a send side issue that can only trigger with
> > TSO enabled, and my next planned chore is to audit the TSO splitting
> > during
On 4/16/06, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
> >
> > Let me save you some time, later in the thread you'll find
> > out that this whole thing is a dead end.
>
> Thanks. I even read the message but managed to miss your conclusi
On Sun, Apr 16, 2006 at 10:32:03PM -0700, David S. Miller wrote:
>
> Let me save you some time, later in the thread you'll find
> out that this whole thing is a dead end.
Thanks. I even read the message but managed to miss your conclusion :)
> So it nearly has to be a send side issue that can o
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Sun, 16 Apr 2006 21:18:31 +1000
> Great eyes! Yes that bug seems to have been around forever. I'll
> look over the patch tomorrow as right now I'm still on west-coast
> time :)
Let me save you some time, later in the thread you'll find
out that this who
Hi David:
I've been flying on and off for the last two days so I only saw this now.
On Fri, Apr 14, 2006 at 08:59:27PM -0700, David S. Miller wrote:
>
> Herbert, as you may have noticed we found some missing
> locking in sk_stream_rfree(). It could explain the
> "!sk_forward_alloc" BUG() we tho
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Sat, 15 Apr 2006 01:23:27 -0700 (PDT)
> I came up with one more possible approach, it goes something like
> this:
>
> 1) Get rid of the skb->destructor callback for TCP receive
>data.
>
> 2) Adjust sk_rmem_alloc and sk_forward_alloc explicitl
From: "David S. Miller" <[EMAIL PROTECTED]>
Date: Fri, 14 Apr 2006 20:59:27 -0700 (PDT)
> Any ideas? Come to think of it, __sk_stream_mem_reclaim() looks
> really racey even as-is.
I came up with one more possible approach, it goes something like
this:
1) Get rid of the skb->destructor callback
11 matches
Mail list logo
