David Miller wrote:
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 3 Aug 2007 14:41:14 +0200
I think this patch could be the final version for now. It has been tested
on two platforms (power and x86_64) and works very well.
I checked in the LRO patch and the two sample driver ports
to
David Miller <[EMAIL PROTECTED]> wrote on 08/09/2007 09:57:27 AM:
>
> > Patrick had suggested calling dev_hard_start_xmit() instead of
> > conditionally calling the new API and to remove the new API
> > entirely. The driver determines whether batching is required or
> > not depending on (skb==NULL)
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Tue, 31 Jul 2007 23:12:06 +0200
> Introduces neigh_cleanup_and_release() to be used after a
> neighbour has been removed from its neighbour table. Serves
> as preparation to add event notifications.
>
> Signed-off-by: Thomas Graf <[EMAIL PROTECTED]>
Ap
From: Thomas Graf <[EMAIL PROTECTED]>
Date: Tue, 31 Jul 2007 23:12:35 +0200
> Currently neighbour event notifications are limited to update
> notifications and only sent if the ARP daemon is enabled. This
> patch extends the existing notification code by also reporting
> neighbours being removed d
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 3 Aug 2007 14:41:14 +0200
> I think this patch could be the final version for now. It has been tested
> on two platforms (power and x86_64) and works very well.
I checked in the LRO patch and the two sample driver ports
to net-2.6.24, thanks!
David Miller wrote:
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:32:34 -0400
Think of a box where you have other network interfaces, the way you
are implementing currently implies you are going to be very unfair to
the other interfaces on the box.
This was the point I was tryin
On Wed, 8 Aug 2007 21:18:25 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 8 Aug 2007, Chris Snook wrote:
> >
> > Some architectures currently do not declare the contents of an atomic_t to
> > be
> > volatile. This causes confusion since atomic_read() might not actually r
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 14:42:50 +0400
> What are your plans about this driver?
I've added it to my net-2.6.24 which I'm building to night.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
Mo
On Sat, 4 Aug 2007, Ray Lee wrote:
On 8/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Sat, 4 Aug 2007, Ingo Molnar wrote:
At least on a surface level, your report has some similarities to
http://lkml.org/lkml/2007/5/21/84 . In that message, John Miller
mentions several things he tried
Hi Dave,
David Miller <[EMAIL PROTECTED]> wrote on 08/09/2007 03:31:37 AM:
> > What do you generally think of the patch/implementation ? :)
>
> We have two driver implementation paths on recieve and now
> we'll have two on send, and that's not a good trend.
Correct.
> In an ideal world all the
From: John Heffner <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:20:05 -0400
> I believe the current calculation is correct. The RFC specifies a
> window of no more than 4380 bytes unless 2*MSS > 4380. If you change
> the code in this way, then MSS=1461 will give you an initial window of
> 3*
From: Stephen Hemminger <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 07:06:28 -0400
> Documentation of NAPI still needs more work. I'll take a start at getting
> net_device docbook format cleaned up, then start on a redo of the API
> documentation.
Thanks for stepping up to do this Stephen.
-
To u
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 08:10:59 -0400
> Its overdue - just hasnt been anybody who has raised their hands
> to do it. Stephen did at one point.
> Theres a lot of nice insights in that doc that will be nice to inherit.
> Theres also a nice state machine diagram in
>
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Thu, 9 Aug 2007 09:49:57 +0530
> Patrick had suggested calling dev_hard_start_xmit() instead of
> conditionally calling the new API and to remove the new API
> entirely. The driver determines whether batching is required or
> not depending on (skb==NU
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:32:34 -0400
> Think of a box where you have other network interfaces, the way you
> are implementing currently implies you are going to be very unfair to
> the other interfaces on the box.
This was the point I was trying to make the othe
On Wed, 8 Aug 2007, Chris Snook wrote:
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses a value stored in a register, which
> can break cod
On Wed, May 30, 2007 at 10:56:27AM -0400, jamal wrote:
>
> On Wed, 2007-30-05 at 11:40 +0200, Patrick McHardy wrote:
> > One good thing about ESFQ is the more flexible flow classification, but
> > I don't like the concept of having a set of selectable hash functions
> > very much.
> >
>
> In the
Hi Patrick,
Patrick McHardy <[EMAIL PROTECTED]> wrote on 08/08/2007 07:35:17 PM:
> Krishna Kumar wrote:
> > +static inline int get_skb(struct net_device *dev, struct Qdisc *q,
> > + struct sk_buff_head *blist, struct sk_buff **skbp)
> > +{
> > + if (likely(!blist || (!skb_queue_len(b
On Wed, Aug 08, 2007 at 06:48:24PM -0700, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Thu, 09 Aug 2007 09:03:27 +0800
>
> > Such loops should always use something like cpu_relax() which comes
> > with a barrier.
>
> This is an excellent point.
>
> And it needs to be weighe
Hi Dave:
[NET]: Share correct feature code between bridging and bonding
http://bugzilla.kernel.org/show_bug.cgi?id=8797 shows that the
bonding driver may produce bogus combinations of the checksum
flags and SG/TSO.
For example, if you bond devices with NETIF_F_HW_CSUM and
NETIF_F_IP_CSUM you'll
Herbert Xu <[EMAIL PROTECTED]> wrote on 08/08/2007 07:12:47 PM:
> On Wed, Aug 08, 2007 at 03:49:00AM -0700, David Miller wrote:
> >
> > Not because I think it obviates your work, but rather because I'm
> > curious, could you test a TSO-in-hardware driver converted to
> > batching and see how TSO a
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 08/08/2007 05:44:02 PM:
> On Wed, Aug 08, 2007 at 03:01:45PM +0530, Krishna Kumar
([EMAIL PROTECTED]) wrote:
> > +static inline int get_skb(struct net_device *dev, struct Qdisc *q,
> > + struct sk_buff_head *blist, struct sk_buff **skbp)
> >
Hi Evgeniy,
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote on 08/08/2007 05:31:43 PM:
> > +int dev_change_tx_batch_skb(struct net_device *dev, unsigned long
new_batch_skb)
> > +{
> > + int ret = 0;
> > + struct sk_buff_head *blist;
> > +
> > + if (!dev->hard_start_xmit_batch) {
> > + /* Dr
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 09:03:27 +0800
> Such loops should always use something like cpu_relax() which comes
> with a barrier.
This is an excellent point.
And it needs to be weighed with the error prone'ness Andrew mentioned.
There probably is a middle ground
Michael Buesch a écrit :
> On Thursday 09 August 2007, Aurelien Jarno wrote:
>> - Add some delay between the configuration of the PCI controller
>>and its registration.
>
> Why? It is _huge_ and people won't like it ;)
> At least add a comment why this is needed.
It is need, otherwise the P
On Thu, Aug 09, 2007 at 02:38:24AM +0200, Aurelien Jarno wrote:
> Michael Buesch a écrit :
> > On Thursday 09 August 2007, Aurelien Jarno wrote:
> >> - Add some delay between the configuration of the PCI controller
> >>and its registration.
> >
> > Why? It is _huge_ and people won't like it
Chris Snook <[EMAIL PROTECTED]> wrote:
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses a value stored in a register, which
> can break code
On Thursday 09 August 2007, Aurelien Jarno wrote:
> - Add some delay between the configuration of the PCI controller
>and its registration.
Why? It is _huge_ and people won't like it ;)
At least add a comment why this is needed.
> @@ -340,6 +345,7 @@
>* The following needs change, i
The patch below against 2.6.23-rc1-mm2 fixes various things on the SSB
PCI core driver:
- Correctly write the configuration register value in
ssb_extpci_write_config() for len = 1 or len = 2.
- Set the PCI latency timer to handle devices on the PCI bus.
- Set the PCI arbiter control to inter
On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
> Heiko Carstens wrote:
> >On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> >>From: Heiko Carstens <[EMAIL PROTECTED]>
> >>Date: Wed, 8 Aug 2007 11:33:00 +0200
> >>
> >>>Just saw this while grepping for atomic_reads in a wh
Hello Herbert,
> > Not because I think it obviates your work, but rather because I'm
> > curious, could you test a TSO-in-hardware driver converted to
> > batching and see how TSO alone compares to batching for a pure
> > TCP workload?
>
> You could even lower the bar by disabling TSO and enablin
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> Jesper Juhl wrote:
> > On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> >> From: Chris Snook <[EMAIL PROTECTED]>
> >>
> >> Some architectures currently do not declare the contents of an atomic_t to
> >> be
> >> volatile. This causes c
Lennert Buytenhek wrote:
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an
Jesper Juhl wrote:
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
From: Chris Snook <[EMAIL PROTECTED]>
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing com
On Wed, Aug 08, 2007 at 07:07:33PM -0400, Chris Snook wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compile
Dave,
> I reverted everything Roland had an issue with, I got tired of arguing
> my position and doing all of the coding too. He won.
Thanks. I think the reschedule in the IPoIB poll should maintain fairness.
Shirley
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
On 09/08/2007, Chris Snook <[EMAIL PROTECTED]> wrote:
> From: Chris Snook <[EMAIL PROTECTED]>
>
> Some architectures currently do not declare the contents of an atomic_t to be
> volatile. This causes confusion since atomic_read() might not actually read
> anything if an optimizing compiler re-uses
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 12:27:35 -0400
> Someone please make sure Documentation/networking/netdevices.txt remains
> correct with regards to APIs and locking.
>
> It -is- up to date, unlike NAPI howto. It should not change very much
> due to this napi_struct
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c |4
drivers/net/e1000e/e1000.h |7 ---
drivers/net/e1000e/es2lan.c |5 +
drivers/net/e1000e/ethtool.c |3 ++-
drivers/net/e1000e/hw.h |2 ++
drivers/net/e1000e/ich8lan.c |5 ++
From: Chris Snook <[EMAIL PROTECTED]>
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can break code that loops
On Wed, 2007-08-08 at 15:22 -0700, David Miller wrote:
> The driver path, however, does not exist on an island and what
> we care about is the final result with the changes running
> inside the full system.
>
> So, to be honest, besides for initial internal development
> feedback, the isolated te
On Wed, 2007-08-08 at 21:55 +0100, Stephen Hemminger wrote:
> > pktgen shows a clear win if you test the driver path - which is what you
> > should test because thats where the batching changes are.
> > Using TCP or UDP adds other variables[1] that need to be isolated first
> > in order to quanti
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 02:31:15PM -0700, Andrew Morton wrote:
On Wed, 08 Aug 2007 17:08:44 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens <[EMAIL PROTECTED]>
Date: We
On Wed, Aug 08, 2007 at 02:31:15PM -0700, Andrew Morton wrote:
> On Wed, 08 Aug 2007 17:08:44 -0400
> Chris Snook <[EMAIL PROTECTED]> wrote:
>
> > Heiko Carstens wrote:
> > > On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> > >> From: Heiko Carstens <[EMAIL PROTECTED]>
> > >> Date:
From: jamal <[EMAIL PROTECTED]>
Date: Wed, 08 Aug 2007 11:14:35 -0400
> pktgen shows a clear win if you test the driver path - which is what
> you should test because thats where the batching changes are.
The driver path, however, does not exist on an island and what
we care about is the final re
From: Shirley Ma <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 08:14:13 -0700
> Dave, could you please hold this portion of the patch for a moment. I will
> test this patch ASAP. According to our previous experience, this changes
> significant changes some IPoIB driver performance.
I reverted everyth
Auke Kok wrote:
Remove labels with only return, remove E1000_SUCCESS code and
replace with 0. Remove most goto's.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/82571.c | 138 +-
drivers/net/e1000e/defines.h |1
drivers/net/e1000e/es2lan.c | 162 ++
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 08 Aug 2007 14:38:10 +0200
> Jeff Garzik <[EMAIL PROTECTED]> writes:
> > > + val, reg_index, addr, addr+4); */
> > > + writel(cpu_to_le32(reg_index), addr);
> > > + writel(cpu_to_le32(val),(u8 *)addr + 4);
> >
> > wrong -- endian conversi
From: Krishna Kumar2 <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 16:39:47 +0530
> What do you generally think of the patch/implementation ? :)
We have two driver implementation paths on recieve and now
we'll have two on send, and that's not a good trend.
In an ideal world all the drivers would be
From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 12:16:51 +0100
> 2. On sparc64 with the same kernel IPV6_PKTINFO works without problems, even
> pulls
> out the cmsg fields correctly. Conversely, when trying to set the
> IPV6_RECVPKTINFO
> sticky option on the socket, no cm
On Wed, 08 Aug 2007 17:08:44 -0400
Chris Snook <[EMAIL PROTECTED]> wrote:
> Heiko Carstens wrote:
> > On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> >> From: Heiko Carstens <[EMAIL PROTECTED]>
> >> Date: Wed, 8 Aug 2007 11:33:00 +0200
> >>
> >>> Just saw this while grepping for at
Brandon,
Before slot_reset event is called io_error_detected could be called
(where pci_disable_device() is called), right?
The pci_reenable_device() will call enable only if the device was
enabled before and would not be enabled if the device were disabled. Is
this the intended behavior?
Ram
Heiko Carstens wrote:
On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
From: Heiko Carstens <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 11:33:00 +0200
Just saw this while grepping for atomic_reads in a while loops.
Maybe we should re-add the volatile to atomic_t. Not sure.
I think
On Wed, 08 Aug 2007 11:14:35 -0400
jamal <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-08 at 21:42 +0800, Herbert Xu wrote:
> > On Wed, Aug 08, 2007 at 03:49:00AM -0700, David Miller wrote:
> > >
> > > Not because I think it obviates your work, but rather because I'm
> > > curious, could you test
On Wed, 2007-08-08 at 13:20 +0200, Mariusz Kozlowski wrote:
> Hello,
>
> Unpatched version does sth like this:
>
> dev = alloc_etherdev(...
> private = netdev_priv(dev);
> ...
> dev->priv = private;
>
> which doesn't make much sense (does it?) because this is done in
> alloc_netdev() alrea
> +static struct ib_mw *nes_alloc_mw(struct ib_pd *ibpd) {
> +get_random_bytes(&next_stag_index, sizeof(next_stag_index));
Could this use up a lot of entropy? Is random32() sufficient?
> +stag_key = (u8)next_stag_index;
I don't think this cast is needed.
> +if (ret) {
> +
Michael Buesch wrote:
On Wednesday 08 August 2007 18:59:08 Jeff Garzik wrote:
Michael Buesch wrote:
writel doesn't guarantee flushing either.
readl does.
Not quite -- there are multiple kinds of flushing. You're thinking
about flushing across PCI bridges, which is correct, but you also have
Hi,
Just added an old network card, RTL-8029(AS), ne2k-pci driver, and tried to
expand the network (failed because I didn't use a cross-over cable).
The code snippet that spat the thing:
/*
* IRQ resend
*
* Is called with interrupts disabled and desc->lock held.
*/
void check_irq_resend(stru
On 10:36 Wed 08 Aug 2007, Kok, Auke wrote:
> Brandon Philips wrote:
>> I sent this last week as part of my devres patches but it is purely a
>> bug fix and can be merged now.
>> On a slot_reset event pci_disable_device() is never called so calling
>> pci_enable_device() will unbalance the enable co
Brandon Philips wrote:
I sent this last week as part of my devres patches but it is purely a
bug fix and can be merged now.
On a slot_reset event pci_disable_device() is never called so calling
pci_enable_device() will unbalance the enable count.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED
On Wednesday 08 August 2007 18:59:08 Jeff Garzik wrote:
> Michael Buesch wrote:
> > writel doesn't guarantee flushing either.
> > readl does.
>
>
> Not quite -- there are multiple kinds of flushing. You're thinking
> about flushing across PCI bridges, which is correct, but you also have
> CPU
> git.openfabrics.org/~glenn/libnes.git
> git.openfabrics.org/~glenn/ofed_1_2.git
> git.openfabrics.org/~glenn/ofascripts.git
> git.openfabrics.org/~glenn/ofed_1_2_scripts.git
these aren't actually git URLs. prepending git:// seems to work though.
-
To unsubscribe from this list: send the lin
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/netdev.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index dd4eca6..741965d 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/n
After moving code around we can reduce namespace usage
by making a few functions static.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000e/e1000.h |2 --
drivers/net/e1000e/lib.c|2 +-
drivers/net/e1000e/netdev.c |2 +-
drivers/net/e1000e/phy.c| 10 ++-
I sent this last week as part of my devres patches but it is purely a
bug fix and can be merged now.
On a slot_reset event pci_disable_device() is never called so calling
pci_enable_device() will unbalance the enable count.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
Acked-by: Tejun Heo <[
Hi all,
Here is a list of some known regressions in 2.6.23-rc2
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk6
Hi all,
Here is a list of some known regressions in 2.6.23-rc2.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
NameRegressions fixed since 21-Jun-2007
Adrian Bunk6
Andi Kleen
Michael Buesch wrote:
writel doesn't guarantee flushing either.
readl does.
Not quite -- there are multiple kinds of flushing. You're thinking
about flushing across PCI bridges, which is correct, but you also have
CPU write posting and CPU write ordering and such.
Without taking all that
On Wed, Aug 08, 2007 at 09:46:16AM -0700, Roland Dreier wrote:
>
> Not mmiowb() -- that is for ordering between CPUs, eg on systems like
> Altix where PCI transactions might get reordered in the system fabric
> before reaching the PCI bus.
>
Yes, that's right. This is a continual source of
> The barrier/ordering issue however might be a critical thing,
> when using __raw_XXX. So one must always mmiowb() after such a write.
Not mmiowb() -- that is for ordering between CPUs, eg on systems like
Altix where PCI transactions might get reordered in the system fabric
before reaching the
On Wednesday 08 August 2007 18:33:24 Jeff Garzik wrote:
> Michael Buesch wrote:
> > On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> >> > But there are indeed a few cases that look wrong.
> >>
> >> yes...
> >>
> >> > arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val),
> >
> Most likely the __raw_writel variant is portable, but I am not
> sure. Anybody sure?
Yes, it should be fine. I use that construct in a few IB drivers.
- R.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info a
Ramkrishna Vepa wrote:
We have a few patches queued and can send this patch in along with ours.
That would be great, thanks.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ker
Michael Buesch wrote:
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
On Wednesday 08 August 2007 18:18:31 Roland Dreier wrote:
> > But there are indeed a few cases that look wrong.
>
> yes...
>
> > arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
>
> eg this almost certainly wants to be
>
> writel(swab32(val), target);
>
> or so
Someone please make sure Documentation/networking/netdevices.txt remains
correct with regards to APIs and locking.
It -is- up to date, unlike NAPI howto. It should not change very much
due to this napi_struct work though, if at all.
Jeff
-
To unsubscribe from this list: send the l
Roland Dreier wrote:
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
__raw_writel(cpu_to_be
We have a few patches queued and can send this patch in along with ours.
Ram
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
> On Behalf Of Jeff Garzik
> Sent: Tuesday, August 07, 2007 2:58 PM
> To: Mariusz Kozlowski
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
And
Andi Kleen wrote:
Jeff Garzik <[EMAIL PROTECTED]> writes:
+ val, reg_index, addr, addr+4); */
+ writel(cpu_to_le32(reg_index), addr);
+ writel(cpu_to_le32(val),(u8 *)addr + 4);
wrong -- endian conversion macros not needed with writel()
Are you sure?
Yes.
r
> But there are indeed a few cases that look wrong.
yes...
> arch/x86_64/kernel/pci-calgary.c: writel(cpu_to_be32(val), target);
eg this almost certainly wants to be
writel(swab32(val), target);
or something equivalent like
__raw_writel(cpu_to_be32(val), target);
Stephen Hemminger writes:
> I don't have a machine with anywhere near enough routes to test this,
> so would someone with many routes give it a go and make sure nothing
> got busted in the process.
Hello!
It's not only the numbers of routes thats important...
Anyway I've done what can
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
This version of the driver is largely the same as the last release:
* Driver uses a single RX and single TX queue, each using 1 MSI-X
irq vector.
* Driver runs
I believe the current calculation is correct. The RFC specifies a
window of no more than 4380 bytes unless 2*MSS > 4380. If you change
the code in this way, then MSS=1461 will give you an initial window of
3*MSS == 4383, violating the spec. Reading the pseudocode in the RFC
3390 is a bit mis
On Wed, 2007-08-08 at 08:14 -0700, Shirley Ma wrote:
> Dave, could you please hold this portion of the patch for a moment. I
> will test this patch ASAP. According to our previous experience, this
> changes significant changes some IPoIB driver performance.
>
If you adjust your quantum while doin
That sounds right to me.
-John
Ilpo Järvinen wrote:
On Mon, 6 Aug 2007, Ilpo Järvinen wrote:
...Goto logic could be cleaner (somebody has any suggestion for better
way to structure it?)
...I could probably move the setting of snd_cwnd earlier to avoid
this problem if this seems a valid
This code is far from a TCP stack. It's main purpose is to exchange
RDMA MPA request/response messages that are required by the iWarp specs
and therefore needed by our hardware. All RNIC hardware vendors need
this MPA message exchange, including those already accepted into
kernel.org. Do you hav
On Wed, 2007-08-08 at 16:05 +0200, Patrick McHardy wrote:
> This is not completely avoidable of
> course, but you can and should limit the damage by only pulling
> out as much packets as the driver can take and have the driver
> stop the queue afterwards.
This why the dev->xmit_win exists in my p
On Wed, 2007-08-08 at 21:42 +0800, Herbert Xu wrote:
> On Wed, Aug 08, 2007 at 03:49:00AM -0700, David Miller wrote:
> >
> > Not because I think it obviates your work, but rather because I'm
> > curious, could you test a TSO-in-hardware driver converted to
> > batching and see how TSO alone compar
Jeff,
Thanks for the input. I'll take your suggestions into account for the
patch v2 posting.
Glenn.
-Original Message-
From: Jeff Garzik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 07, 2007 8:58 PM
To: Glenn Grundstrom
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.o
Krishna Kumar wrote:
> + * Algorithm to get skb(s) is:
> + * - Non batching drivers, or if the batch list is empty and there is
> + * 1 skb in the queue - dequeue skb and put it in *skbp to tell the
> + * caller to use the single xmit API.
> + * - Batching drivers where the batch list a
On Wednesday 08 August 2007 15:48:25 Michael Buesch wrote:
> > However if that's true then there are quite some drivers wrong:
> >
> > % grep -r write[bwl]\(cpu_to * | wc -l
> > 57
>
> Yeah, seems so.
Most of them seem to be
__raw_writew(cpu_toXX(...
which I think might be valid.
But there a
On Wednesday 08 August 2007 15:38:50 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
> > On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> > > On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > > > On Wednesday 08 August 2007 14:55:11 Andi
On Wed, Aug 08, 2007 at 03:49:00AM -0700, David Miller wrote:
>
> Not because I think it obviates your work, but rather because I'm
> curious, could you test a TSO-in-hardware driver converted to
> batching and see how TSO alone compares to batching for a pure
> TCP workload?
You could even lower
On Wed, Aug 08, 2007 at 07:58:21AM +0200, Mariusz Kozlowski wrote:
> > Please send wireless patches to [EMAIL PROTECTED],
> > and CC me.
>
> Ok. Did you pick the patch up?
Yes, I have it.
John
--
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe netd
On Wed, Aug 08, 2007 at 03:28:33PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > > > On Wed, Aug 08, 2007 at 01:50:35PM +0200,
On Wed, Aug 08, 2007 at 02:17:09PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
> This throttling mechanism allows to limit maximum amount of queued bios
> per physical device. By default it is turned off and old block layer
> behaviour with unlimited number of bios is used. When turned on
On Wednesday 08 August 2007 15:08:28 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> > On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > > On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > > > On Wednesday 08 August 2007 14:38:10 Andi
IPoIB CM & Multicast changes based on header file changes.
Signed-off-by: Krishna Kumar <[EMAIL PROTECTED]>
---
ipoib_cm.c| 13 +
ipoib_multicast.c |4 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
diff -ruNp ORG/drivers/infiniband/ulp/ipoib/ipoib_cm.c
NEW/dri
On Wed, 8 Aug 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Tue, 7 Aug 2007 16:19:58 +0300 (EEST)
>
> > Do you have any suggestion how I should proceed? Or do you perhaps object
> > such partial merge completely? ...I could try to come up with a cleaned up
> > pa
On Wed, Aug 08, 2007 at 03:02:35PM +0200, Michael Buesch wrote:
> On Wednesday 08 August 2007 14:55:11 Andi Kleen wrote:
> > On Wed, Aug 08, 2007 at 01:50:35PM +0200, Michael Buesch wrote:
> > > On Wednesday 08 August 2007 14:38:10 Andi Kleen wrote:
> > > > Jeff Garzik <[EMAIL PROTECTED]> writes:
>
1 - 100 of 151 matches
Mail list logo
