Denys a écrit :
Hi
I got
pi linux-git # git bisect bad
Bisecting: 0 revisions left to test after this
[f85958151900f9d30fa5ff941b0ce71eaa45a7de] [NET]: random functions can use
nsec resolution instead of usec
I will make sure and will try to reverse this patch on 2.6.22
But it seems "that'
On Sun, 30 Sep 2007, jamal wrote:
> This patch adds the usage of batching within the core.
>
> cheers,
> jamal
> [sep30-p2of3 text/plain (6.8KB)]
> [NET_BATCH] net core use batching
>
> This patch adds the usage of batching within the core.
> The same test methodology used in introducing txl
Hi all,
I am new to this list, so please forgive me if I say anything
inappropriate.
I am working on a mobility testbed based on IPv6. In order to improve
the performance, I would like to remove the DAD process during the
auto-configuration process of an IPv6 address for my testbed.
During my e
Hi Yoshifuji,
YOSHIFUJI Hideaki / wrote:
Dave, Brian,
Let me double check this patch.
Regards,
--yoshfuji
In article <[EMAIL PROTECTED]> (at Fri, 28 Sep 2007 17:50:38 -0700), David Stevens
<[EMAIL PROTECTED]> says:
Brian,
A multicast address should never be the target of a ne
jamal wrote:
> On Sun, 2007-30-09 at 15:23 -0400, Jeff Garzik wrote:
>
>> Gotta wait a bit, otherwise we have confusion and a bit of breakage from
>> two drivers with the same PCI IDs.
>
> ah, ok ;->
> When i was testing i compiled out e1000. I am willing to totaly migrate
> to e1000e, since ma
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 19:47:17 -0700
> On Fri, 2007-09-21 at 10:49 -0700, David Miller wrote:
> > From: Denys Vlasenko <[EMAIL PROTECTED]>
> > Date: Fri, 21 Sep 2007 18:03:55 +0100
> >
> > > Do patches look ok to you?
> >
> > I'm travelling so I haven't
From: Alexey Kuznetsov <[EMAIL PROTECTED]>
Date: Fri, 21 Sep 2007 19:55:22 +0400
> Hello!
>
> Remove artificial limitation for sfq queue limit.
>
> This is followup to Patrick's patch. A little optimization to enqueue
> routine allows to remove artificial limitation on queue length.
>
> Plus, t
From: Varun Chandramohan <[EMAIL PROTECTED]>
Date: Thu, 20 Sep 2007 20:57:51 +0530
> @@ -420,6 +421,7 @@ static int fn_hash_insert(struct fib_tab
> else
> fa = fib_find_alias(&f->fn_alias, tos, fi->fib_priority);
>
> + do_gettimeofday(&tv);
> /* Now fa, if non-NULL,
Hi Dave,
This is the last remaining patch for IrDA, against net-2.6.24.
It fixes a kernel oops triggered by the ksdazzle SIR driver.
We need more space for input frames, and 2048 should be plenty of it.
Signed-off-by: Alex Villacís Lasso <[EMAIL PROTECTED]>
Signed-off-by: Samuel Ortiz <[EMAIL PR
On Sun, 2007-30-09 at 15:23 -0400, Jeff Garzik wrote:
> Gotta wait a bit, otherwise we have confusion and a bit of breakage from
> two drivers with the same PCI IDs.
ah, ok ;->
When i was testing i compiled out e1000. I am willing to totaly migrate
to e1000e, since major machine i have access t
jamal wrote:
On Sun, 2007-30-09 at 11:16 -0700, Kok, Auke wrote:
no, all the hardware that is commented should work just fine. I tested this
driver
on 82571, 82573 and ich8/ich9 - extensively.
Something else is wrong then. Can you just uncomment the 82571EB bits in
Dave's net-2.6.24 and just
And heres a patch that provides a sample of the usage for batching with
tg3.
Requires patch "[TG3]Some cleanups" i posted earlier.
cheers,
jamal
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 5a864bd..9aafb78 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3103,6 +3103,13 @
On Sun, 2007-30-09 at 11:16 -0700, Kok, Auke wrote:
> no, all the hardware that is commented should work just fine. I tested this
> driver
> on 82571, 82573 and ich8/ich9 - extensively.
Something else is wrong then. Can you just uncomment the 82571EB bits in
Dave's net-2.6.24 and just send a pin
Fixed subject - should be 1/3 not 1/4
On Sun, 2007-30-09 at 14:51 -0400, jamal wrote:
> This patch introduces the netdevice interface for batching.
>
> cheers,
> jamal
>
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
This patch removes dev->gso_skb as it is no longer necessary with
batching code.
cheers,
jamal
[NET_SCHED] kill dev->gso_skb
The batching code does what gso used to batch at the drivers.
There is no more need for gso_skb. If for whatever reason the
requeueing is a bad idea we are going to leave
This patch adds the usage of batching within the core.
cheers,
jamal
[NET_BATCH] net core use batching
This patch adds the usage of batching within the core.
The same test methodology used in introducing txlock is used, with
the following results on different kernels:
++-
This patch introduces the netdevice interface for batching.
cheers,
jamal
[NET_BATCH] Introduce batching interface
This patch introduces the netdevice interface for batching.
A typical driver dev->hard_start_xmit() has 4 parts:
a) packet formating (example vlan, mss, descriptor counting etc)
Latest net-2.6.24 breaks the patches i posted last week; so this is an
update to resolve that. If you are receiving these emails and are
finding them overloading, please give me a shout and i will remove your
name.
Please provide feedback on the code and/or architecture.
Last time i posted them i
jamal wrote:
> Auke,
>
> heres part of something i promised.
> I couldnt do any packet testing on because 82571EB is disabled in the
> driver. I uncommented the code out in the table, but the best i could
> get was the module loading, some probing and some sysfs renaming
> failures (probably a de
On Sun, 2007-30-09 at 14:11 -0400, jamal wrote:
> Here are some non-batching related changes that i have in my batching
> tree. Like the e1000e, they make the xmit code more readable.
> I wouldnt mind if you take them over.
Should have mentioned: Against Dave's tree from a few hours back.
cheers,
Here are some non-batching related changes that i have in my batching
tree. Like the e1000e, they make the xmit code more readable.
I wouldnt mind if you take them over.
cheers,
jamal
[TG3] Some cleanups
These cleanups make the xmit path code better functionally organized.
Matt Carlson contribut
Auke,
heres part of something i promised.
I couldnt do any packet testing on because 82571EB is disabled in the
driver. I uncommented the code out in the table, but the best i could
get was the module loading, some probing and some sysfs renaming
failures (probably a debianism); the machine acces
Hi,
I booted 2.6.23-rc8 and noticed that ehea loves its workqueues:
# ps aux|grep ehea
root 3266 0.0 0.000 ?S< 11:02 0:00 [ehea_driver_wq/]
root 3268 0.0 0.000 ?S< 11:02 0:00 [ehea_driver_wq/]
root 3269 0.0 0.000 ?S< 11:02 0:00
Herbert Xu wrote:
> On Sat, Sep 29, 2007 at 05:32:41PM +0200, Patrick McHardy wrote:
>
>>For unicast addresses its not strictly necessary since they may
>>only be changed under the RTNL anyway. The reason why it takes
>>the tx_lock is for consistency with multicast address handling,
>>which can't
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>Maybe I can save you some time: we used to do down_trylock()
>>for the rtnl mutex, so senders would simply return if someone
>>else was already processing the queue *or* the rtnl was locked
>>for some other reason. In th
Herbert Xu wrote:
> On Sun, Sep 30, 2007 at 08:26:01AM +0800, Herbert Xu wrote:
>
>>Indeed. The only other case I can think of is defragmentation.
>>But even there we should be able to squeeze it into the original
>>skb :)
>
>
> OK it won't be pretty but it's definitely doable. We simply
> swa
Hmm, so it looks like we do not need this queue processing at all...
Regards,
Den
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>> Maybe I can save you some time: we used to do down_trylock()
>> for the rtnl mutex, so senders would simply return if someone
>> e
> OK. Did you try to reproduce it without the pps patch applied?
No. But I've yanked the ip1000a driver (using old crufy vendor-supplied
out-of-kernel module) and the problems are GONE.
>> This machine receives more data than it sends, so I'd expect acks to
>> outnumber "real" packets. Could t
On 30 Sep 2007 03:59:56 -0400 [EMAIL PROTECTED] wrote:
> > ntpd. Sounds like pps leaking to me.
>
> That's what I'd think, except that pps does no allocation in the normal
> running state, so there's nothing to leak. The interrupt path just
> records the time in some preallocated, static buffer
> ntpd. Sounds like pps leaking to me.
That's what I'd think, except that pps does no allocation in the normal
running state, so there's nothing to leak. The interrupt path just
records the time in some preallocated, static buffers and wakes up
blocked readers. The read path copies the latest d
30 matches
Mail list logo
