From: Eric Dumazet <dada1@cosmosbay.com> This adds new overhead for TCP which has to hold the socket lock for other reasons in these paths. I don't get how an atomic_t operation is cheaper than a lock_sock/release_sock. Is it the case that in many executions of these paths only atomic_read()'s are necessary? I actually think this scheme is racy. There is a reason we have to hold the socket lock when doing memory scheduling. Two threads can get in there and say "hey I have enough ...

IMO, a better solution could be to add a dummy ipv6 module that returns -EOPNOTSOPP or appropriate for most calls. --

Thanks Eric --

Thanks for your pointer. I cloned net-next-2.6 tree. skb_record_rx_queue is a smart idea to implement an auto TX selection. There is no NIC multi-queue standard or RFC available. At least I didn't find it by google. Both the new skb_record_rx_queue and current kernel have an assumption on multi-queue. The assumption is it's best to send out packets from the TX of the same number of queue like the one of RX if the receved packets are related to the out packets. Or more direct speaking is we ...

From: Roel Kluin <roel.kluin@gmail.com> I'll make sure to integrate this version of your patch instead of the original which I just said I applied :-) --

From: "Matt Carlson" <mcarlson@broadcom.com> Sure, I'll queue it up to net-2.6 --

From: Yi Zou <yi.zou@intel.com> I am fine with these changes, they look good. --

I'm maintaining vlan :) I haven't been able to look into this yet, but I should be later today. --

From: Patrick McHardy <kaber@trash.net> Ok, I don't actually care who fixes it :-) I asked Stephen because this appears like it might be netdev_ops fallout. --

Well, since ISATAP is just a SIT, it still needs a link local address for=20 autoconf and it needs to have it's v4 Address embedded in the lowest 32 bit= of=20 the linklocal address. It will then do normal autoconf with the potential=20 router by sending a proper router solicitation messages, either directed or= =20 multicast. I see that the current implementation disables sending of RS when on ISATAP= ,=20 which is not correct because RS are needed to do the autoconf. Well, the current ...

Maybe good idea to use strace? (i dont know which flags useful, but usually i use "-s 65536") Just maybe it will give a bit more ideas what is happening. But sure netdev developers can tell, if it is useful or not. --

... Joao, you don't need to be sorry at all - on the contrary I'm extremely sorry! I was so focused on the kernel version but ignored updating iproute, and it looks like this matters here. So you're right. Alas I'll not be able to look at it until "tomorrow" in the evening. Thanks for the report, Jarek P. --

From: Sathya Perla <sathyap@serverengines.com> Although these pointers are properly declared with the __iomem marker, the code in some places fails to specify the __iomem qualifier. For example, be_mbox_db_ring(), be_mbox_db_ready_wait(). I am sure there are others. If you check your driver's build with sparse it will warn about these kinds of problems. --

very well, I'll make the change, and repost in a few days when I have it all tested. Neil --

ROTFL, I have to get that book someday... For now I'm reading a brick That would be better than kfree_skb_clean, yes. - Arnaldo P.S.: Neil, I didn't managed to get to the other aspects of your work, sorry about being so picky :-\ --

Check the RFC thread. The cases in which we are dropping far outnumber the set of cases in which we free the skb simply because its the end of the line. Theres far less churn this way Neil --

Oh well, sometimes churn is inevitable, but lemme try to figure out some more clearer names for kfree_skb_clean: rest_in_peace_skb() here_lies_a_productive_skb() kfree_not_dropped_skb() kfree_worthy_skb() consumed_skb() hasta_la_vista_skbaby() kfree_used_skb() Perhaps the last one, huh? :-) - Arnaldo P.S.: </joke'ishy moment> --

I wouldn't mind the churn, as I really think drop_skb() would be clearer, but then this is up to Dave. - Arnaldo --

It should also be noted that netlink attributes only provide 4 byte alignment. Not sure what the current status of handling unaligned accesses on all architectures is, but something that might have to be taken into consideration. --

From: Meelis Roos <mroos@linux.ee> Applied, thanks. --

yes - please consider it fixed. Thanks, Ingo --

From: Ron Mercer <ron.mercer@qlogic.com> All applied to net-next-2.6, thanks Ron. --

This patch isn't needed since I can't think of any sane reason why the hdr_delta subtraction would ever cause an error. Similarly, I don't think David's concerns over the icsk_ext_hdr_len adjustment necessarily apply here either. Let me try and explain, feel free to point out faults in my logic ... This function, cipso_v4_sock_delattr(), is only used _to_ remove the CIPSO IP option from a socket, never to add it. In the code snippet above we see the following three lines: hdr_delta ...

Amazing how this kept hidden for so long. I could have sworn I've already seen the notification errors in userspace :) --

From: Alexander Duyck <alexander.h.duyck@intel.com> The L0s workaround should be moved into a pci quirk and so it is not necessary in the driver. This update removes the L0s workaround from the igb driver. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> --- drivers/net/igb/igb_main.c | 26 ++------------------------ 1 files changed, 2 insertions(+), 24 deletions(-) diff --git a/drivers/net/igb/igb_main.c ...

From: Alexander Duyck <alexander.h.duyck@intel.com> This patch is intended to disable L0s ASPM link state for 82598 (ixgbe) parts due to the fact that it is possible to corrupt TX data when coming back out of L0s on some systems. The workaround had been added for 82575 (igb) previously, but did not use the ASPM api. This quirk uses the ASPM api to prevent the ASPM subsystem from re-enabling the L0s state. Instead of adding the fix in igb to the ixgbe driver as well it was decided to move it ...

From: Andrey Borzenkov <arvidjaar@gmail.com> No, Brian's patches are is the only reasonable way to fix this bug, even in 2.6.29 We not going to let the ipv6 module load disable hack live any longer, sorry. I'm going to apply and push out Brian's patches.

From: Brian Haley <brian.haley@hp.com> Applied, but you have to do something about your email client and what it does to patches Brian. Every line that starts with a single space then TABs was replaced with two space characters then the TABs. Long lines were also chopped up. --

Add "disable" module parameter support to ipv6.ko by specifying "disable=1" on module load. We just do the minimum of initializing inetsw6[] so calls from other modules to inet6_register_protosw() won't OOPs, then bail out. No IPv6 addresses or sockets can be created as a result, and a reboot is required to enable IPv6. Signed-off-by: Brian Haley <brian.haley@hp.com> --- Documentation/networking/ipv6.txt | 35 +++++++++++++++++++++++++++++++++++ net/ipv6/af_inet6.c | ...

Change sctp_ctl_sock_init() to try IPv4 if IPv6 socket registration fails. Required if the IPv6 module is loaded with "disable=1", else SCTP will fail to load. Signed-off-by: Brian Haley <brian.haley@hp.com> Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- net/sctp/protocol.c | 11 ++++++++--- 1 files changed, 8 insertions(+), 3 deletions(-) diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c index c1e316e..e8c6287 100644 --- a/net/sctp/protocol.c +++ ...

The limitation to only 1500 byte mtu's limits the utility of the veth device for testing routing. So implement implement a configurable MTU. For consistency I drop packets on the receive side when they are larger than the MTU. I count those drops. And I allow a little padding for vlan headers. I also test the mtu when a new device is created with netlink because that path currently bypasses the current mtu setting code. Signed-off-by: Eric Biederman ...

Currently, tmspci tokenring driver crashes on device initialization because it requests its irq before initializing corresponding data structures. Fix this by moving request_irq call to a safer place. Signed-off-by: Meelis Roos <mroos@linux.ee> diff --git a/drivers/net/tokenring/tmspci.c b/drivers/net/tokenring/tmspci.c index 5f60177..e2150b3 100644 --- a/drivers/net/tokenring/tmspci.c +++ b/drivers/net/tokenring/tmspci.c @@ -121,11 +121,6 @@ static int __devinit tms_pci_attach(struct ...

This patch from Juha Leppanen suppresses a false warning if the eeprom load succeeds on the very last attempt. Juha> In function smsc911x_open smsc911x_reg_read+udelay can be run 50 Juha> times with timeout reaching -1, and the following if statetement Juha> does not catch the timeout and no warning is issued. Also if the Juha> 50th smsc911x_reg_read is GOOD, loop is exited with timeout as 0 Juha> and bogus warning issued. Replace testing order and --timeout Juha> instead of timeout-- and now ...

Are you talking about the kernel or the iproute package? The git tree I was referring to was the iproute tools package. http://www.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git Thanks, Alex --

2.6.29-rc6-git7 I will try rc7 now --

Hi trying to do test case: defaulthost ~ # tc qdisc del dev eth0 root handle 1: htb defaulthost ~ # tc qdisc add dev eth0 root handle 1: htb defaulthost ~ # tc class add dev eth0 parent 1:0 classid 1:1 htb rate 100Mbit ceil 100Mbit defaulthost ~ # defaulthost ~ # tc class add dev eth0 parent 1:1 classid 1:2 htb rate 100Mbit ceil 100Mbit defaulthost ~ # tc qdisc add dev eth0 parent 1:2 handle 2: pfifo limit 1000 defaulthost ~ # defaulthost ~ # defaulthost ~ # tc filter add dev eth0 pref ...

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/tx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/sfc/tx.c b/drivers/net/sfc/tx.c index 9f97e44..b1e1907 100644 --- a/drivers/net/sfc/tx.c +++ b/drivers/net/sfc/tx.c @@ -400,7 +400,7 @@ void efx_xmit_done(struct efx_tx_queue *tx_queue, unsigned int index) * separates the update of read_count from the test of * stopped. */ smp_mb(); - if (unlikely(tx_queue->stopped)) ...

When flushing queues we disable normal interrupt and event handling and poll event queue 0 looking for flush completions. Unfortunately the flush event polling loop fails to move past any other type of event. This problem has not been observed in production hardware but appears to be a possibility. Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- drivers/net/sfc/falcon.c | 21 +++++++++------------ 1 files changed, 9 insertions(+), 12 deletions(-) diff --git ...

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com> --- This is necessary because netif_carrier_off() doesn't stop the queue immediately. Ben. drivers/net/sfc/tx.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/net/sfc/tx.c b/drivers/net/sfc/tx.c index da3e9ff..9f97e44 100644 --- a/drivers/net/sfc/tx.c +++ b/drivers/net/sfc/tx.c @@ -376,6 +376,9 @@ int efx_hard_start_xmit(struct sk_buff *skb, struct net_device *net_dev) struct efx_nic *efx = ...

From: Mike Travis <travis@sgi.com> Change error message when alloc_cpumask_var fails. Signed-off-by: Mike Travis <travis@sgi.com> Acked-by: Ben Hutchings <bhutchings@solarflare.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- drivers/net/sfc/efx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/net/sfc/efx.c~sfc-modify-allocation-error-message drivers/net/sfc/efx.c --- ...