* Re: [PATCH] netxen: drop redudant spinlock
From: Jeff Garzik @ 2007-07-30 19:52 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0707272257090.27724@stellar.unminc.com>
Dhananjay Phadke wrote:
> Some leftover code that makes use of adapter->lock in tx_timeout function,
> which resets the interface under this lock. In close() when the workqueue
> is flushed, prints the warning about sleeping with interrupts disabled
> (when spinlock debug is enabled). The lock was required with private netxen
> IOCTLs, which were removed a while ago.
applied
^ permalink raw reply
* Re: [RESEND 1/2] netxen: re-init station address after h/w init
From: Jeff Garzik @ 2007-07-30 19:52 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, rob
In-Reply-To: <20070725144515.533385702@netxen.com>
dhananjay@netxen.com wrote:
> This is a workaround for firmware bug with 2nd port of multiport adapter,
> where MAC address is reset. Driver just needs to overwrite it with the
> value read from PROM.
>
> Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
applied 1-2
^ permalink raw reply
* Re: [PATCH] forcedeth: mac address correct
From: Jeff Garzik @ 2007-07-30 19:50 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Manfred Spraul, Andrew Morton, nedev
In-Reply-To: <46A96A78.1050008@nvidia.com>
Ayaz Abdulla wrote:
> Resending:
>
> In older chipsets, the mac address was stored in reversed order.
> However, in newer chipsets, the mac address is in correct order. This
> patch takes those newer chipsets into account and does not rely on a
> special bit setup by BIOS'.
>
> Signed-Off-By: Ayaz Abdulla <aabdulla@nvidia.com>
applied
^ permalink raw reply
* Re: [PATCH] tulip: Remove tulip maintainer
From: Jeff Garzik @ 2007-07-30 19:50 UTC (permalink / raw)
To: Valerie Henson; +Cc: netdev, linux-kernel, tulip-users
In-Reply-To: <20070730191052.GB16182@rainbow>
Valerie Henson wrote:
> Remove Val Henson as tulip maintainer and let her roam free, FREE!
>
> Signed-off-by: Val Henson <val@nmt.edu>
applied
^ permalink raw reply
* Re: [PATCH][netdrvr] lib8390: comment on locking by Alan Cox Re: 2.6.20->2.6.21 - networking dies after random time
From: Jeff Garzik @ 2007-07-30 19:47 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Alan Cox, Thomas Gleixner, Ingo Molnar, Linus Torvalds,
Marcin ??lusarz, Jean-Baptiste Vignaud, linux-kernel, shemminger,
linux-net, netdev, Andrew Morton, Paul Gortmaker
In-Reply-To: <20070726124401.GC3423@ff.dom.local>
Jarek Poplawski wrote:
> Hi,
>
> Very below is my patch proposal with a comment, which in my opinion
> is precious enough to save it for future help in reading and
> understanding the code.
>
> I hope Alan will not blame me I've not asked for his permission before
> sending, and he would ack this patch as it is or at least most of this.
>
> Thanks & regards,
> Jarek P.
>
> On Wed, Jul 25, 2007 at 03:46:56PM +0100, Alan Cox wrote:
>>>> The code in question lib8390.c does
>>>>
>>>> disable_irq();
>>>> fiddle_with_the_network_card_hardware()
>>>> enable_irq();
>>> ...
>>>> No idea how this affects the network card, as the code there must be
>>>> able to handle interrupts, which are not originated from the card due to
>>>> interrupt sharing.
>>> I think, in this last yesterday's patch Ingo could be right, yet!
>>> The comment at the beginnig points this is done like that because
>>> of chip's slowness. And problems with timing are mysterious.
>>>
>>> On the other hand author of this code didn't use spin_lock_irqsave
>>> for some reason, probably after testing this option too. So, I hope
>>> this is the right path, but alas, I'm not sure this patch has to
>>> prove this 100%.
>> The author (me) didn't use spin_lock_irqsave because the slowness of the
>> card means that approach caused horrible problems like losing serial data
>> at 38400 baud on some chips. Rememeber many 8390 nics on PCI were ISA
>> chips with FPGA front ends.
>>
>>> Anyway, in my opinion this situation where interrupts could/have_to
>>> be used for such strange things should confirm the need of more
>>> options for handling irqs individually.
>> Ok the logic behind the 8390 is very simple:
>>
>> Things to know
>> - IRQ delivery is asynchronous to the PCI bus
>> - Blocking the local CPU IRQ via spin locks was too slow
>> - The chip has register windows needing locking work
>>
>> So the path was once (I say once as people appear to have changed it
>> in the mean time and it now looks rather bogus if the changes to use
>> disable_irq_nosync_irqsave are disabling the local IRQ)
>>
>>
>> Take the page lock
>> Mask the IRQ on chip
>> Disable the IRQ (but not mask locally- someone seems to have
>> broken this with the lock validator stuff)
>> [This must be _nosync as the page lock may otherwise
>> deadlock us]
>> Drop the page lock and turn IRQs back on
>>
>> At this point an existing IRQ may still be running but we can't
>> get a new one
>>
>> Take the lock (so we know the IRQ has terminated) but don't mask
>> the IRQs on the processor
>> Set irqlock [for debug]
>>
>> Transmit (slow as ****)
>>
>> re-enable the IRQ
>>
>>
>> We have to use disable_irq because otherwise you will get delayed
>> interrupts on the APIC bus deadlocking the transmit path.
>>
>> Quite hairy but the chip simply wasn't designed for SMP and you can't
>> even ACK an interrupt without risking corrupting other parallel
>> activities on the chip.
>>
>> Alan
>>
> ------>
>
> From: Jarek Poplawski <jarkao2@o2.pl>
>
> Subject: lib8390: comment on locking by Alan Cox
>
> Additional explanation of problems with locking by Alan Cox.
>
> Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Cc: Paul Gortmaker <p_gortmaker@yahoo.com>
> Cc: Jeff Garzik <jeff@garzik.org>
applied
^ permalink raw reply
* Re: [PATCH] gfar: Fix modpost warning
From: Jeff Garzik @ 2007-07-30 19:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: netdev, linuxppc-dev, Andy Fleming
In-Reply-To: <Pine.LNX.4.64.0707260051550.30449@blarg.am.freescale.net>
Kumar Gala wrote:
> Fix the following modpost warning:
>
> WARNING: vmlinux.o(.init.text+0x1aa6c): Section mismatch: reference to .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/net/gianfar_mii.c | 2 +-
> drivers/net/gianfar_mii.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
applied
^ permalink raw reply
* Re: [PATCH] [2.6.22] Fix a potential NULL pointer dereference in write_bulk_callback() in drivers/net/usb/pegasus.c
From: Jeff Garzik @ 2007-07-30 19:45 UTC (permalink / raw)
To: Micah Gruber; +Cc: petkan, linux-kernel, netdev
In-Reply-To: <46A46160.9080508@gmail.com>
Micah Gruber wrote:
> This patch fixes a potential null dereference bug where we dereference
> pegasus before a null check. This patch simply moves the dereferencing
> after the null check.
>
> Signed-off-by: Micah Gruber <micah.gruber@gmail.com>
>
> ---
>
> --- a/drivers/net/usb/pegasus.c
> +++ b/drivers/net/usb/pegasus.c
> @@ -768,11 +768,13 @@
> static void write_bulk_callback(struct urb *urb)
> {
> pegasus_t *pegasus = urb->context;
> - struct net_device *net = pegasus->net;
> + struct net_device *net;
>
> if (!pegasus)
> return;
>
> + net = pegasus->net;
> +
applied (manually)
^ permalink raw reply
* Re: [TULIP] Need new maintainer
From: Kyle McMartin @ 2007-07-30 19:31 UTC (permalink / raw)
To: Valerie Henson
Cc: netdev, linux-kernel, tulip-users, Grant Grundler, Jeff Garzik
In-Reply-To: <20070730190412.GA16182@rainbow>
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote:
> The Tulip network driver needs a new maintainer! I no longer have
> time to maintain the Tulip network driver and I'm stepping down. Jeff
> Garzik would be happy to get volunteers.
>
Since I already take care of a major consumer of these devices (parisc,
which pretty much all have tulip) I'm willing to take care of this.
Alternately, Grant is probably willing.
Cheers,
Kyle
^ permalink raw reply
* Re: [PATCH] possible deadlock in tulip driver
From: Valerie Henson @ 2007-07-30 19:12 UTC (permalink / raw)
To: Denis V. Lunev; +Cc: netdev, davem, tulip-users, devel
In-Reply-To: <20070724074908.GA15258@iris.sw.ru>
(No longer maintainer, btw.)
What situation have you tested this under? Thanks,
-VAL
On Tue, Jul 24, 2007 at 11:49:08AM +0400, Denis V. Lunev wrote:
> Calling flush_scheduled_work() may deadlock if called under rtnl_lock
> (from dev->stop) as linkwatch_event() may be on the workqueue and it will try
> to get the rtnl_lock
>
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> ---
>
> tulip_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- ./drivers/net/tulip/tulip_core.c.tulip 2007-07-16 12:54:29.000000000 +0400
> +++ ./drivers/net/tulip/tulip_core.c 2007-07-23 19:06:24.000000000 +0400
> @@ -726,8 +726,6 @@ static void tulip_down (struct net_devic
> void __iomem *ioaddr = tp->base_addr;
> unsigned long flags;
>
> - flush_scheduled_work();
> -
> del_timer_sync (&tp->timer);
> #ifdef CONFIG_TULIP_NAPI
> del_timer_sync (&tp->oom_timer);
> @@ -1788,6 +1786,8 @@ static void __devexit tulip_remove_one (
> if (!dev)
> return;
>
> + flush_scheduled_work();
> +
> tp = netdev_priv(dev);
> unregister_netdev(dev);
> pci_free_consistent (pdev,
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] tulip: Remove tulip maintainer
From: Valerie Henson @ 2007-07-30 19:10 UTC (permalink / raw)
To: netdev, linux-kernel, tulip-users; +Cc: Jeff Garzik
Remove Val Henson as tulip maintainer and let her roam free, FREE!
Signed-off-by: Val Henson <val@nmt.edu>
--- linux-2.6.orig/MAINTAINERS
+++ linux-2.6/MAINTAINERS
@@ -3569,11 +3569,9 @@ W: http://www.auk.cx/tms380tr/
S: Maintained
TULIP NETWORK DRIVER
-P: Valerie Henson
-M: val@nmt.edu
L: tulip-users@lists.sourceforge.net
W: http://sourceforge.net/projects/tulip/
-S: Maintained
+S: Orphan
TUN/TAP driver
P: Maxim Krasnyansky
^ permalink raw reply
* [TULIP] Need new maintainer
From: Valerie Henson @ 2007-07-30 19:04 UTC (permalink / raw)
To: netdev, linux-kernel, tulip-users; +Cc: Grant Grundler, Jeff Garzik
The Tulip network driver needs a new maintainer! I no longer have
time to maintain the Tulip network driver and I'm stepping down. Jeff
Garzik would be happy to get volunteers.
The only current major outstanding patch I know of is Grant's shutdown
race patch, which was incorrectly dropped as obsoleted from -mm (my
fault, I was moving at the time):
http://www.mail-archive.com/mm-commits@vger.kernel.org/msg12161.html
I have a very much non-working patch to do it with the preferred
order, ask me for it and I'll see if I can dig it up. It's unpleasant
partly because it pointed out a lot of latent bugs (e.g.,
del_timer_sync() in interrupt context).
Also, someone is working on support for an emulated Tulip card (yes,
Tulip will _never_ die), so expect possible patches for that.
-VAL
^ permalink raw reply
* Re: Linksys Gigabit USB2.0 adapter (asix) regression
From: David Hollis @ 2007-07-30 18:27 UTC (permalink / raw)
To: Erik Slagter; +Cc: netdev
In-Reply-To: <46ADAF1B.4060500@slagter.name>
On Mon, 2007-07-30 at 11:27 +0200, Erik Slagter wrote:
> They are either garbled are they are not passed on the wire. The
> transmitted packets are shown by tshark, but a tshark run on "the other
> end of the line" does not show them.
>
> Platform is indeed x86, to be precise: fedora 7, kernel 2.6.22-rc6, cpu
> pentium M, dell laptop inspiron 9300, ICH6.
>
> If you want me to test something please yell, it's no trouble at all to
> change a few lines in the driver's source and recompile the module.
>
Could you send me a complete dmesg dump when the driver is compiled with
DEBUG enabled (at least from then usb logs that the device was inserted
to the end). I'll need to see what it reports the values of the
registers.
Have you tried using the F7 2.6.22 kernel? I know that has worked fine
for me on my system.
> Please note I cannot send mail to you: "(conversation with
> dhollis.dyndns.org[71.251.104.159] timed out while sending MAIL FROM)"
I've fixed that issue so my mail delivery isn't sporadic.
--
David Hollis <dhollis@davehollis.com>
^ permalink raw reply
* Re: [PATCH] SMSC LAN911x and LAN921x vendor driver
From: Steve.Glendinning @ 2007-07-30 18:31 UTC (permalink / raw)
To: Peter Korsgaard
Cc: Bahadir Balban, Bill Gatliff, Dustin Mcintire, ian.saturley,
netdev
In-Reply-To: <874pjn3paf.fsf@p4.be.48ers.dk>
Hi Peter,
> What's the problem with Dustin's driver? It seems to work fine here
> with a lan9117. Why not just add lan921x support to the existing
> driver?
I have heard Dustin's driver works very well on PXA, but on others it
doesn't even compile (hence why it depends on ARCH_PXA).
Dustin's driver was based on the smc91x code, but these two ethernet
devices share nothing other than a similar name. smsc911x is a new,
completely platform-independent driver with workarounds for several
hardware issues, and it doesn't suffer from quite as much macro abuse :-)
Regards,
--
Steve Glendinning
SMSC GmbH
m: +44 777 933 9124
e: steve.glendinning@smsc.com
^ permalink raw reply
* Re: [PATCH] NET_DMA: remove unused dma_memcpy_to_kernel_iovec
From: Christoph Hellwig @ 2007-07-30 18:14 UTC (permalink / raw)
To: pravin
Cc: David Miller, shannon.nelson, netdev, viro, christopher.leech,
andy.grover
In-Reply-To: <bab433300707300739s283bf15fp9d00235cf39fa08b@mail.gmail.com>
On Mon, Jul 30, 2007 at 08:09:53PM +0530, pravin wrote:
> comments?
please avoid using plain sendmsg/recvmsg from kernelspace. Adding these
segment checks is more than a bad hack and not something that should
clutter up fasthpathes. Add to that problems with kthreads vs blocking
recvmsg and you have a bigger mess than you can handle.
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin @ 2007-07-30 17:43 UTC (permalink / raw)
To: Linas Vepstas
Cc: Jan-Bernd Themann, netdev, Thomas Klein, Jeff Garzik,
Jan-Bernd Themann, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder, Stefan Roscher, David Miller
In-Reply-To: <20070730170038.GA4884@austin.ibm.com>
Here is a quick reply before something more official can
be written up:
Linas Vepstas wrote:
> -- what is LRO?
Large Receive Offload
> -- Basic principles of operation?
LRO is analogous to a receive side version of TSO. The NIC (or
driver) merges several consecutive segments from the same connection,
fixing up checksums, etc. Rather than up to 45 separate 1500 byte
frames (meaning up to 45 trips through the network stack), the driver
merges them into one 65212 byte frame. It currently works only
with TCP over IPv4.
LRO was, AFAIK, first though of by Neterion. They had a paper about
it at OLS2005.
http://www.linuxinsight.com/files/ols2005/grossman-reprint.pdf
> -- Can I use it in my driver?
Yes, it can be used in any driver.
> -- Does my hardware have to have some special feature before I can
use it?
No.
> -- What sort of performance improvement does it provide? Throughput?
> Latency? CPU usage? How does it affect DMA allocation? Does it
> improve only a certain type of traffic (large/small packets, etc.)
The benefit is directly proportional to the packet rate.
See my reply to the previous RFC for performance information. The
executive summary is that for the myri10ge 10GbE driver on low end
hardware with 1500b frames, I've seen it increase throughput by a
factor of nearly 2.5x, while at the same time reducing CPU utilization
by 17%. The affect for jumbo frames is less dramatic, but still
impressive (1.10x, 14% CPU reduction)
You can achieve better speedups if your driver receives into
high-order pages.
> -- Example code? What's the API? How should my driver use it?
The 3/4 in this patch showed an example of converting a driver
to use LRO for skb based receive buffers. I'm working on
a patch for myri10ge that shows how you would use it in a driver
which receives into pages.
Cheers,
Drew
^ permalink raw reply
* [PATCH net-2.6 2/2] [TCP]: Bidir flow must not disregard SACK blocks for lost marking
From: Ilpo Järvinen @ 2007-07-30 17:19 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0707301947210.8788@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1551 bytes --]
It's possible that new SACK blocks that should trigger new LOST
markings arrive with new data (which previously made is_dupack
false). In addition, I think this fixes a case where we get
a cumulative ACK with enough SACK blocks to trigger the fast
recovery (is_dupack would be false there too).
I'm not completely pleased with this solution because readability
of the code is somewhat questionable as 'is_dupack' in SACK case
is no longer about dupacks only but would mean something like
'lost_marker_work_todo' too... But because of Eifel stuff done
in CA_Recovery, the FLAG_DATA_SACKED check cannot be placed to
the if statement which seems attractive solution. Nevertheless,
I didn't like adding another variable just for that either... :-)
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 767f92c..cfe6ac7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2109,7 +2109,10 @@ tcp_fastretrans_alert(struct sock *sk, u32 prior_snd_una,
{
struct inet_connection_sock *icsk = inet_csk(sk);
struct tcp_sock *tp = tcp_sk(sk);
- int is_dupack = (tp->snd_una == prior_snd_una && !(flag&FLAG_NOT_DUP));
+ int is_dupack = (tp->snd_una == prior_snd_una &&
+ (!(flag&FLAG_NOT_DUP) ||
+ ((flag&FLAG_DATA_SACKED) &&
+ (tp->fackets_out > tp->reordering))));
/* Some technical things:
* 1. Reno does not count dupacks (sacked_out) automatically. */
--
1.5.0.6
^ permalink raw reply related
* [PATCH net-2.6 1/2] [TCP]: Fix ratehalving with bidirectional flows
From: Ilpo Järvinen @ 2007-07-30 17:18 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
In-Reply-To: <Pine.LNX.4.64.0707301947210.8788@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1996 bytes --]
Actually, the ratehalving seems to work too well, as cwnd is
reduced on every second ACK even though the packets in flight
remains unchanged. Recoveries in a bidirectional flows suffer
quite badly because of this, both NewReno and SACK are affected.
After this patch, rate halving is performed for ACK only if
packets in flight was supposedly changed too.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
---
net/ipv4/tcp_input.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 0163051..767f92c 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1848,19 +1848,22 @@ static inline u32 tcp_cwnd_min(const struct sock *sk)
}
/* Decrease cwnd each second ack. */
-static void tcp_cwnd_down(struct sock *sk)
+static void tcp_cwnd_down(struct sock *sk, int flag)
{
struct tcp_sock *tp = tcp_sk(sk);
int decr = tp->snd_cwnd_cnt + 1;
+
+ if ((flag&FLAG_FORWARD_PROGRESS) ||
+ (IsReno(tp) && !(flag&FLAG_NOT_DUP))) {
+ tp->snd_cwnd_cnt = decr&1;
+ decr >>= 1;
- tp->snd_cwnd_cnt = decr&1;
- decr >>= 1;
+ if (decr && tp->snd_cwnd > tcp_cwnd_min(sk))
+ tp->snd_cwnd -= decr;
- if (decr && tp->snd_cwnd > tcp_cwnd_min(sk))
- tp->snd_cwnd -= decr;
-
- tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1);
- tp->snd_cwnd_stamp = tcp_time_stamp;
+ tp->snd_cwnd = min(tp->snd_cwnd, tcp_packets_in_flight(tp)+1);
+ tp->snd_cwnd_stamp = tcp_time_stamp;
+ }
}
/* Nothing was retransmitted or returned timestamp is less
@@ -2057,7 +2060,7 @@ static void tcp_try_to_open(struct sock *sk, int flag)
}
tcp_moderate_cwnd(tp);
} else {
- tcp_cwnd_down(sk);
+ tcp_cwnd_down(sk, flag);
}
}
@@ -2257,7 +2260,7 @@ tcp_fastretrans_alert(struct sock *sk, u32 prior_snd_una,
if (is_dupack || tcp_head_timedout(sk))
tcp_update_scoreboard(sk);
- tcp_cwnd_down(sk);
+ tcp_cwnd_down(sk, flag);
tcp_xmit_retransmit_queue(sk);
}
--
1.5.0.6
^ permalink raw reply related
* [PATCH net-2.6 0/2] [TCP]: Fix bidirectional brokeness
From: Ilpo Järvinen @ 2007-07-30 17:16 UTC (permalink / raw)
To: David Miller; +Cc: Netdev
Hi Dave,
While testing frto with bidirection TCP a while (months) ago, I
encountered time-seq graphs which made absolutely no sense as if
recoveries only completed after RTO. As a result, I noticed that
rate-halving has problem when a flow is bidirection but testing the
patch has been on my todo list for ages. ...Finally, here it is...
...Please think the first one a bit because there might be some
corner cases with reno.
While testing it I came across with an additional issue that can
occur with bidirectional traffic. And, even better, the second fix
seems to also solves a third issue which affects both unidirectional
and bidirectional flows, though it's a marginal case (cumulative
ACK that causes a larger number of new SACKed skbs). I've never
seen that third one to occur but it's there if you get enough ACK
losses, subsequent ACKs (if one gets them) do solve it so that's
not a very bad issue to begin with...
I've verified these from time-seq graphs on top of tcp-2.6, which
had some additional (mostly cleanup and the rebase I promised you
earlier) though I added the tp->fackets_out > tp->reordering check
afterwards as it seems necessary to avoid going to lost marker too
often (wouldn't have had any effect in my test case anyway).
...Please consider to net-2.6 and to stable too.
These will generate you some hassle when you rebase tcp-2.6. Btw, you
forgot to push tcp-2.6 out last time though I could assume it's
state... :-) In case you're going to now push it out, could you please
drop "[TCP]: Remove num_acked>0 checks from cong.ctrl mods pkts_acked"
from it as it seems to be out of place in tcp-2.6, I can resubmit it
to net-2.6.24 when you open it (unless you want to put it to net-2.6
directly as it's rather trivial one).
--
i.
^ permalink raw reply
* Re: [RFC] fib_trie: whitespace cleanup
From: Paul E. McKenney @ 2007-07-30 17:07 UTC (permalink / raw)
To: Andrew Morton
Cc: Stephen Hemminger, Adrian Bunk, Robert Olsson, Ingo Molnar,
Josh Triplett, netdev
In-Reply-To: <20070726215630.96f971d4.akpm@linux-foundation.org>
On Thu, Jul 26, 2007 at 09:56:30PM -0700, Andrew Morton wrote:
> On Thu, 26 Jul 2007 08:44:21 -0700 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> > On Thu, Jul 26, 2007 at 11:49:42AM +0100, Stephen Hemminger wrote:
> > > Whitespace cleanup run code through lindent then cleanup results.
> > > Applys after other two patches.
> > >
> > > --- a/net/ipv4/fib_trie.c 2007-07-26 10:17:21.000000000 +0100
> > > +++ b/net/ipv4/fib_trie.c 2007-07-26 11:47:52.000000000 +0100
> > > @@ -156,7 +156,8 @@ struct trie {
> > > };
> > >
> > > static void put_child(struct trie *t, struct tnode *tn, int i, struct node *n);
> > > -static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n, int wasfull);
> > > +static void tnode_put_child_reorg(struct tnode *tn, int i, struct node *n,
> > > + int wasfull);
> > > static struct node *resize(struct trie *t, struct tnode *tn);
> > > static struct tnode *inflate(struct trie *t, struct tnode *tn);
> > > static struct tnode *halve(struct trie *t, struct tnode *tn);
> > > @@ -167,13 +168,12 @@ static struct trie *trie_local = NULL, *
> > >
> > > static inline struct tnode *node_parent(struct node *node)
> > > {
> > > - return rcu_dereference((struct tnode *) (node->parent & ~NODE_TYPE_MASK));
> > > + return rcu_dereference((struct tnode *)(node->parent & ~NODE_TYPE_MASK));
> >
> > The potential issue is applying rcu_dereference() to an rvalue
> > as opposed to an lvalue. So how about the following?
> >
>
> I did this:
>
> static inline struct tnode *node_parent(struct node *node)
> {
> struct tnode *ret;
>
> ret = (struct tnode *)(node->parent & ~NODE_TYPE_MASK);
> return rcu_dereference(ret);
> }
I would feel more comfortable with the rcu_dereference() covering the
initial fetch from node->parent, but do not have any hard objections
to your approach.
Thanx, Paul
^ permalink raw reply
* Re: [PATCH 2/4][RFC] lro: Kconfig and Makefile
From: Kok, Auke @ 2007-07-30 17:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Stephen Hemminger, Jan-Bernd Themann, netdev, Christoph Raisch,
Jan-Bernd Themann, linux-kernel, linux-ppc, Marcus Eder,
Thomas Klein, Stefan Roscher, David Miller, Andrew Gallatin
In-Reply-To: <46AE1383.3050305@garzik.org>
Jeff Garzik wrote:
> Stephen Hemminger wrote:
>> Why make this a user selectable option at all? Unless you want
>> to deal with out of tree drivers (not my problem), it should be hidden
>> to avoid having to explain an support it.
>
> In this case it's an optional library kernel module. That seems to be a
> common setup for library modules. We do the same with CONFIG_MII and
> drivers/net/mii.ko as well.
>
> Originally it was done purely in the Makefile, but that does not account
> for net drivers in sub-directories (or out of tree as you point out).
speaking of that, shouldn't there be a NETIF_F_LRO ?
Auke
^ permalink raw reply
* Re: [PATCH 0/4][RFC] lro: Generic Large Receive Offload for TCP traffic
From: Linas Vepstas @ 2007-07-30 17:00 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: netdev, Thomas Klein, Jeff Garzik, Jan-Bernd Themann,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <200707301724.33865.ossthema@de.ibm.com>
On Mon, Jul 30, 2007 at 05:24:33PM +0200, Jan-Bernd Themann wrote:
>
> Changes to http://www.spinics.net/lists/netdev/msg36912.html
>
> 1) A new field called "features" has been added to the net_lro_mgr struct.
> It is set by the driver to indicate:
> - LRO_F_NAPI: Use NAPI / netif_rx to pass packets to stack
>
> - LRO_F_EXTRACT_VLAN_ID: Set by driver if HW extracts VLAN IDs for VLAN
> packets but does not modify ETH protocol (ETH_P_8021Q)
>
> 2) Padded frames are not aggregated for now. Bug fixed
>
> 3) Correct header length now used. No minimal header length for aggregated
> packets used anymore.
>
> 4) Statistic counters were introduced. They are stored in a new struct in
> the net_lro_mgr. This has the advantage that no locking is required in
> cases where the driver uses multiple lro_mgrs for different receive queues.
> Thus we get the following statistics per lro_mgr / eth device:
> - Number of aggregated packets
> - Number of flushed packets
> - Number of times we run out of lro_desc.
>
> The ratio of "aggregated packets" and "flushed packets" give you an
> idea how well LRO is working.
I'd like to see an edited form of this, together with an introduction to
LRO, written up in the Documentation subdirectory.
As someone with some driver experience, but not on te bleeding edge,
some basc newbie questions pop into mind:
-- what is LRO?
-- Basic principles of operation?
-- Can I use it in my driver?
-- Does my hardware have to have some special feature before I can use it?
-- What sort of performance improvement does it provide? Throughput?
Latency? CPU usage? How does it affect DMA allocation? Does it
improve only a certain type of traffic (large/small packets, etc.)
-- Example code? What's the API? How should my driver use it?
Right now, I can maybe find answers by doing lots of googling. I'd like
to have some quick way of getting a grip on this.
--linas
^ permalink raw reply
* Re: [PATCH 3/4][RFC] ehea: LRO support
From: Kok, Auke @ 2007-07-30 16:37 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Christoph Raisch, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <200707301724.49829.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Added LRO support using the "SKB aggregate" interface
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> ---
> drivers/net/ehea/ehea.h | 9 ++++-
> drivers/net/ehea/ehea_ethtool.c | 15 +++++++
> drivers/net/ehea/ehea_main.c | 82 +++++++++++++++++++++++++++++++++++---
> 3 files changed, 98 insertions(+), 8 deletions(-)
<snip>
> +module_param(use_lro, int, 0);
> +module_param(lro_max_aggr, int, 0);
this should obviously (and Stephen H. probably agrees) be implemented in ethtool
instead, and opens up the question as to what changes we need to add to ethtool. ..
Auke
^ permalink raw reply
* Re: [PATCH 2/4][RFC] lro: Kconfig and Makefile
From: Jeff Garzik @ 2007-07-30 16:36 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Christoph Raisch, linux-ppc, Jan-Bernd Themann, Marcus Eder,
Andrew Gallatin, Stefan Roscher, David Miller
In-Reply-To: <20070730172535.15993806@oldman.hamilton.local>
Stephen Hemminger wrote:
> Why make this a user selectable option at all? Unless you want
> to deal with out of tree drivers (not my problem), it should be hidden
> to avoid having to explain an support it.
In this case it's an optional library kernel module. That seems to be a
common setup for library modules. We do the same with CONFIG_MII and
drivers/net/mii.ko as well.
Originally it was done purely in the Makefile, but that does not account
for net drivers in sub-directories (or out of tree as you point out).
Jeff
^ permalink raw reply
* Re: [2/3] 2.6.23-rc1: known regressions v3
From: Michal Piotrowski @ 2007-07-30 16:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andrew Morton, LKML, Len Brown, Denis Sadykov, dth, Netdev,
Stephen Hemminger, Thomas Meyer, Florian Lohoff,
Ismail Dönmez, linux-acpi, linux-scsi, James Bottomley,
James Smart, Adrian Bunk
In-Reply-To: <46AE0F5D.3000500@googlemail.com>
Hi all,
Here is a list of some known regressions in 2.6.23-rc1.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 6
Andi Kleen 4
Andrew Morton 4
Linus Torvalds 4
Al Viro 3
Jens Axboe 3
Tejun Heo 3
David Woodhouse 2
Hugh Dickins 2
CPUFREQ/ACPI
Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
References : http://lkml.org/lkml/2007/7/27/298
http://lkml.org/lkml/2007/7/29/371
Last known good : ?
Submitter : dth <dth@dth.net>
Caused-By : ?
Handled-By : ?
Status : unknown
Networking
Subject : sky2 boot crash in sky2_mac_intr
References : http://lkml.org/lkml/2007/7/24/91
Last known good : ?
Submitter : Florian Lohoff <flo@rfc822.org>
Caused-By :
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : unknown
Subject : New wake ups from sky2
References : http://lkml.org/lkml/2007/7/20/386
Last known good : ?
Submitter : Thomas Meyer <thomas@m3y3r.de>
Caused-By : Stephen Hemminger <shemminger@osdl.org>
commit eb35cf60e462491249166182e3e755d3d5d91a28
Handled-By : Stephen Hemminger <shemminger@osdl.org>
Status : unknown
Power Management
Subject : New ACPI error/warning with Linus' latest GIT
References : http://lkml.org/lkml/2007/7/26/395
Last known good : ?
Submitter : Ismail Dönmez <ismail@pardus.org.tr>
Caused-By : ?
Handled-By : ?
Status : unknown
SCSI
Subject : lpfc_sli.c: off-by-10
References : http://lkml.org/lkml/2007/7/22/284
Last known good : ?
Submitter : Adrian Bunk <bunk@stusta.de>
Caused-By : ?
Handled-By : ?
Status : unknown
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4][RFC] lro: Kconfig and Makefile
From: Stephen Hemminger @ 2007-07-30 16:25 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: netdev, Christoph Raisch, Jan-Bernd Themann, linux-kernel,
linux-ppc, Marcus Eder, Thomas Klein, Stefan Roscher,
David Miller, Andrew Gallatin, Jeff Garzik
In-Reply-To: <200707301724.45781.ossthema@de.ibm.com>
On Mon, 30 Jul 2007 17:24:45 +0200
Jan-Bernd Themann <ossthema@de.ibm.com> wrote:
> Kconfig and Makefile for LRO
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> ---
> net/ipv4/Kconfig | 8 ++++++++
> net/ipv4/Makefile | 1 +
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index fb79097..d894f61 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -394,6 +394,14 @@ config INET_XFRM_MODE_BEET
>
> If unsure, say Y.
>
> +config INET_LRO
> + tristate "Large Receive Offload (ipv4/tcp)"
> +
> + ---help---
> + Support for Large Receive Offload (ipv4/tcp).
> +
> + If unsure, say Y.
> +
Why make this a user selectable option at all? Unless you want
to deal with out of tree drivers (not my problem), it should be hidden
to avoid having to explain an support it.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox