On Wed, Aug 17, 2005 at 11:53:31PM -0700, Jay Vosburgh wrote:
>
> Some; I've been working on it over time since we discussed it
> last time, and have gone through a couple of prototypes that didn't work
> out. I think I've got an overall reworking of things (link monitoring,
> that yucky io
Herbert Xu <[EMAIL PROTECTED]> wrote:
>Andrew Morton <[EMAIL PROTECTED]> wrote:
>> {:bonding:alb_set_slave_mac_addr+76}
>> [ 158.024233]{:bonding:alb_swap_mac_addr+170}
>> {:bonding:bond_change_active_slave+546}
>> [ 158.024373]{:bonding:bond_mii_monitor+1012}
>> {:bonding:bond_m
Coywolf Qi Hunt a écrit :
On 8/18/05, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Andi Kleen a écrit :
(because of the insane struct file_ra_state f_ra. I wish this structure
were dynamically allocated only for files that really use it)
How about you submit a patch for that instead?
-Andi
Andi Kleen wrote:
You don't want to always have bad performance though, so you
could attempt to allocate if either the pointer is null _or_ it
points to the global structure?
Remember it's after a GFP_KERNEL OOM. If that fails most likely
you have deadlocked somewhere else already because Lin
> You don't want to always have bad performance though, so you
> could attempt to allocate if either the pointer is null _or_ it
> points to the global structure?
Remember it's after a GFP_KERNEL OOM. If that fails most likely
you have deadlocked somewhere else already because Linux's handling
of
Andi Kleen wrote:
I would just set the ra pointer to a single global structure if the allocation
fails. Then you can avoid all the other checks. It will slow down
things and trash some state, but not fail and nobody should expect good
performance after out of memory anyways. The only check sti
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 03:05:25 +0200
> I would just set the ra pointer to a single global structure if the
> allocation fails. Then you can avoid all the other checks. It will
> slow down things and trash some state, but not fail and nobody
> should expect goo
Andrew Morton <[EMAIL PROTECTED]> wrote:
> [ 158.023763] RTNL: assertion failed at net/ipv4/devinet.c (962)
> [ 158.023819]
> [ 158.023820] Call Trace: {rt_run_flush+48}
> {inetdev_event+116}
> [ 158.023964]{rt_run_flush+123}
> {notifier_call_chain+31}
> [ 158.024094]{dev_set_
Ken-ichirou MATSUZAWA <[EMAIL PROTECTED]> wrote:
>
> It seems that because ipcomp_alloc_tfms() calls smp_processor_id(),
> but a comment says not need locking. Is this right?
Yes the comment is right. I'll fix it up.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV
On Wed, Aug 17, 2005 at 02:48:25PM -0700, Jay Vosburgh wrote:
> John W. Linville <[EMAIL PROTECTED]> wrote:
> >Signed-off-by: Jay Vosburg <[EMAIL PROTECTED]>
>
> Pretty close.
>
> Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>
Ooops...sorry! Tired, sloppy typing... :-(
> I believ
On 8/18/05, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Andi Kleen a écrit :
>
> >
> >>(because of the insane struct file_ra_state f_ra. I wish this structure
> >>were dynamically allocated only for files that really use it)
> >
> >
> > How about you submit a patch for that instead?
> >
> > -Andi
>
On Thu, Aug 18, 2005 at 02:40:46AM +0200, Eric Dumazet wrote:
> Andi Kleen a ?crit :
>
> >
> >>(because of the insane struct file_ra_state f_ra. I wish this structure
> >>were dynamically allocated only for files that really use it)
> >
> >
> >How about you submit a patch for that instead?
> >
>
Andi Kleen a écrit :
(because of the insane struct file_ra_state f_ra. I wish this structure
were dynamically allocated only for files that really use it)
How about you submit a patch for that instead?
-Andi
OK, could you please comment this patch ?
The problem of dynamically allocati
Stephen Hemminger wrote:
On Wed, 17 Aug 2005 23:28:13 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
Some "L3 switches" do it by violating the layers and faking an ICMP
fragmentation unreachable from the destination for DF=1 and otherwise
fragmenting. But it's a big hack and probably nothing tha
On Wed, 17 Aug 2005 23:28:13 +0200
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Some "L3 switches" do it by violating the layers and faking an ICMP
> fragmentation unreachable from the destination for DF=1 and otherwise
> fragmenting. But it's a big hack and probably nothing that
> should be put
From: "John W. Linville" <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 16:49:59 -0400
> Change operations on rif_lock from spin_{un}lock_bh to
> spin_{un}lock_irq{save,restore} equivalents. Some of the
> rif_lock critical sections are called from interrupt context via
> tr_type_trans->tr_add_rif_inf
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Tue, 16 Aug 2005 12:02:31 +1000
> I have a suggestion as to where fclone_ref
> should be though. I'd put it outside sk_buff. So when you
> allocate sk_buff * 2 for fast clones, make that
> sk_buff * 2 + atomic_t. Then you will only have to carry
> it a
> No no, the private_data is actually far beyond, even for a L1_CACHE_LINE of
> 128 bytes
Yuck.
>
> (because of the insane struct file_ra_state f_ra. I wish this structure
> were dynamically allocated only for files that really use it)
How about you submit a patch for that instead?
-Andi
-
John W. Linville <[EMAIL PROTECTED]> wrote:
>Change operations on rif_lock from spin_{un}lock_bh to
>spin_{un}lock_irq{save,restore} equivalents. Some of the
>rif_lock critical sections are called from interrupt context via
>tr_type_trans->tr_add_rif_info. The TR NIC drivers call tr_type_trans
>
Andi Kleen a écrit :
David, do you think we could place file->private_data in the same cache
line than file->f_count and file->f_op, so that sockfd_lookup() can access
all the needed information (f_count, f_op, private_data) using one
L1_CACHE_LINE only ?
You mean for 32byte cache lines? Not
Some "L3 switches" do it by violating the layers and faking an ICMP
fragmentation unreachable from the destination for DF=1 and otherwise
fragmenting. But it's a big hack and probably nothing that
should be put into Linux.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe netde
From: Daniel Phillips <[EMAIL PROTECTED]>
Date: Thu, 18 Aug 2005 06:50:35 +1000
> One solution is to use a more modern card for the outside interface.
> But is there any fundamental problem with fragmenting the bridge
> traffic when necessary, and let the bridge MTU be the maximum of the
> interfa
On Thursday 18 August 2005 07:02, John Heffner wrote:
> 1) Bridging occurs at the link layer (ethernet); fragmenting occurs at the
> network layer (IP).
>
> 2) A lot of protocols set the Don't Fragment bit, so you can't always
> fragment anyway.
>
> What you might want to do is set it up as an IP r
> David, do you think we could place file->private_data in the same cache
> line than file->f_count and file->f_op, so that sockfd_lookup() can access
> all the needed information (f_count, f_op, private_data) using one
> L1_CACHE_LINE only ?
You mean for 32byte cache lines? Not sure if there a
Change operations on rif_lock from spin_{un}lock_bh to
spin_{un}lock_irq{save,restore} equivalents. Some of the
rif_lock critical sections are called from interrupt context via
tr_type_trans->tr_add_rif_info. The TR NIC drivers call tr_type_trans
from their packet receive handlers.
Signed-off-by
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 22:06:05 +0200
> Then I wait first that Benjamin patch is included. :)
It's in my net-2.6.14 tree already.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Wednesday 17 August 2005 04:50 pm, Daniel Phillips wrote:
> Hi,
>
> I've found that with the GigE interfaces I have here, MTU=9000 improves
> throughput by about 31% versus MTU=1500. I run a fast network for my
> cluster (crossover cable actually) bridged to the outside world over an old
> card
David S. Miller a écrit :
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 21:37:21 +0200
David, do you think we could place file->private_data in the same cache line than file->f_count and file->f_op, so that sockfd_lookup() can
access all the needed information (f_count, f_op, p
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Wed, 17 Aug 2005 21:37:21 +0200
> David, do you think we could place file->private_data in the same cache line
> than file->f_count and file->f_op, so that sockfd_lookup() can
> access all the needed information (f_count, f_op, private_data) using one
Benjamin LaHaise a écrit :
Please consider the patch below which makes use of file->private_data to
store the pointer to the socket, which avoids touching several unused
cachelines in the dentry and inode in sockfd_lookup.
Signed-off-by: Benjamin LaHaise <[EMAIL PROTECTED]>
diff -purN 00_v2.6
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Tue, 16 Aug 2005 22:01:04 -0700
> On Tue, 16 Aug 2005 20:37:25 -0700 (PDT)
> "David S. Miller" <[EMAIL PROTECTED]> wrote:
>
> > Robert was independantly working on an RCU patch, which recently he
> > sent to Paul McKenney for review. We should tr
From: Christoph Hellwig <[EMAIL PROTECTED]>
Subject: Re: [PATCH netdev-2.6] sky2: new experimental Marvell Yukon2 driver
Date: Wed, 17 Aug 2005 20:27:40 +0100
> On Wed, Aug 17, 2005 at 03:25:30PM -0400, Jeff Garzik wrote:
> > >>It's just highly irregular to use pci_unmap_xxx functions immediately
On Wed, Aug 17, 2005 at 03:25:30PM -0400, Jeff Garzik wrote:
> >>It's just highly irregular to use pci_unmap_xxx functions immediately
> >>after calling a pci_map_xxx function.
> >
> >
> >Did you know that pci_unmap_addr_set() is a macro that hides the fact
> >that some arch need iommu but for man
Stephen Hemminger wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
| > +
| > +paddr = pci_map_single(sky2->hw->pdev, re->skb->data,
| > + rx_buf_size, PCI_DMA_FROMDEVICE);
| > +
| > +pci_unmap_len_set(re, maplen, rx_buf_size);
|
Can you please at least _COMPILE_ the patches you post
so that my time isn't wasted like this?
include/linux/ethtool.h:259: error: two types specified in one empty declaration
Of course, you missed the semi-colon:
+struct ethtool_perm_addr {
+ u32 cmd;/* ETHTOOLGPERMADDR *
On Wed, 17 Aug 2005 14:30:31 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
> > |
> > | Applied to 'sky2' branch of netdev-2.6.git. Let me know when the RX
> > | hangs are fixed, and we can push upstream.
> >
> > Okay. Most all of your comments are straightforward
> >
Stephen Hemminger wrote:
|
| Applied to 'sky2' branch of netdev-2.6.git. Let me know when the RX
| hangs are fixed, and we can push upstream.
Okay. Most all of your comments are straightforward
and fixes will be in the next version, but some need
a little more discussion...
|
| > +static v
Stephen Hemminger wrote:
Jeff observed a problem with sky2 driver where if pci_request_regions
failed, the probe code would disable the device. Since if request_regions
fails, this means another device is conflicting, disabling the device
seems to be the wrong.
This problem seems to occur in alm
On Wed, Aug 17, 2005 at 11:10:34AM -0700, Stephen Hemminger wrote:
> Jeff observed a problem with sky2 driver where if pci_request_regions
> failed, the probe code would disable the device. Since if request_regions
> fails, this means another device is conflicting, disabling the device
> seems to b
On Wed, Aug 17, 2005 at 01:21:18PM -0400, Joshua Wise wrote:
> > The bug is that ipv6 is doing an operation to handle MIB statistics and
> > the MIPS architecture math routines seem to need to sleep.
Except nothing in the network stack is using fp - the use of FP inside the
MIPS kernel is not sup
|
| Applied to 'sky2' branch of netdev-2.6.git. Let me know when the RX
| hangs are fixed, and we can push upstream.
Okay. Most all of your comments are straightforward
and fixes will be in the next version, but some need
a little more discussion...
|
| > +static void gm_phy_write(struct sky
Jeff observed a problem with sky2 driver where if pci_request_regions
failed, the probe code would disable the device. Since if request_regions
fails, this means another device is conflicting, disabling the device
seems to be the wrong.
This problem seems to occur in almost all PCI drivers I look
On Wednesday 17 August 2005 12:43, Stephen Hemminger wrote:
> You will get more response to network issues on netdev@vger.kernel.org
Okay. Thanks.
> NAPI poll is usually called from softirq context. This means that
> hardware interrupts are enabled, but it is not in a thread context that
> can sl
On Wed, 17 Aug 2005 09:32:10 -0400
Joshua Wise <[EMAIL PROTECTED]> wrote:
> Hello LKML,
You will get more response to network issues on netdev@vger.kernel.org
> I have recently been working on a network driver for an emulated ultra-simple
> network card, and I've run into a few snags with the
Begin forwarded message:
Date: Wed, 17 Aug 2005 07:20:36 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 5080] New: bonding related oops on boot
http://bugzilla.kernel.org/show_bug.cgi?id=5080
Summary: bonding related oops on boot
Kernel Version: 2
Hello,
It seems that because ipcomp_alloc_tfms() calls smp_processor_id(),
but a comment says not need locking. Is this right?
BUG: using smp_processor_id() in preemptible [0001] code: ipcomp/2801
caller is ipcomp_init_state+0x170/0x490
Call Trace:{debug_smp_processor_id+182}
{ipcomp
Amin Azez wrote:
Work well done, so oughtn't div64_64 to go in
include/asm-generic/div64.h one day, to be available kernel wide, as
do_div64_64
I see that net/core/pktgen.c is full of 64 bit division and maybe could
benefit from this, and perhaps a version that does remainders too.
So far noth
47 matches
Mail list logo
