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
Herbert, as you may have noticed we found some missing
locking in sk_stream_rfree(). It could explain the
"!sk_forward_alloc" BUG() we thought was caused by e1000's
TSO implementation and the Intel folks have provided enough
datapoints to prove that it is indeed not an e1000 specific
problem.
sk
12 matches
Mail list logo
