* Re: [PATCH 0/3]: fixes for multicast routing rules
From: David Miller @ 2010-04-15 21:14 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <1271335678-20961-1-git-send-email-kaber@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 15 Apr 2010 14:47:55 +0200
> the following three patches fix a few bugs introduced by the multicast routing
> rule patches:
...
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/ipmr-2.6.git master
Pulled, thanks a lot Patrick!
^ permalink raw reply
* Re: [PATCH] ip: Fix ip_dev_loopback_xmit()
From: David Miller @ 2010-04-15 21:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: eparis, netdev, therbert
In-Reply-To: <1271358783.16881.2949.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 15 Apr 2010 21:13:03 +0200
> [PATCH] ip: Fix ip_dev_loopback_xmit()
Applied to net-2.6, thanks Eric.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-04-15
From: David Miller @ 2010-04-15 21:29 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100415200331.GD3020@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 15 Apr 2010 16:03:31 -0400
> Another fix intended for 2.6.34...without it some firmware wierdness can
> induce the driver into hanging the box... :-(
>
> Please let me know if there are problems!
Pulled, thanks.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-04-15
From: David Miller @ 2010-04-15 21:31 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20100415205358.GA6659@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 15 Apr 2010 16:53:59 -0400
> Here is another huge dump of wireless bits intended for 2.6.35... It is
> mostly drivers, and mostly the "usual suspects" of those -- ath5k,
> ath9k, iwlwifi, rt2x00, wl1271, and others. There are also some
> infrastructure bits from Johannes and Jouni, including some tracing
> stuff.
>
> Please let me know if there are problems!
Pulled, thanks John!
> P.S. Please note the "for-davem" after the git url... :-)
Yep, saw it :-)
^ permalink raw reply
* Re: NULL pointer dereference panic in stable (2.6.33.2), amd64
From: David Miller @ 2010-04-15 21:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: krkumar2, netdev, nuclearcat
In-Reply-To: <1271364375.16881.3099.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 15 Apr 2010 22:46:15 +0200
> Le jeudi 15 avril 2010 à 22:30 +0200, Eric Dumazet a écrit :
>>
>> @@ -1938,6 +1928,8 @@ gso:
>> if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
>> skb_dst_drop(nskb);
>>
>> + skb_orphan(nskb);
>> +
>> rc = ops->ndo_start_xmit(nskb, dev);
>> if (unlikely(rc != NETDEV_TX_OK)) {
>> if (rc & ~NETDEV_TX_MASK)
>
> Well, might need to test if skb is not shared before orphaning it
>
> if (!skb_shared(skb))
> skb_orphan(nskb);
If it's not legal to skb_orphan() here then it would not be legal for
the drivers to unconditionally skb_orphan(), which they do.
So either your test is unnecessary, or we have a big existing problem
:-)
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] net: replace ipfragok with skb->local_df
From: David Miller @ 2010-04-15 22:33 UTC (permalink / raw)
To: shanwei
Cc: herbert, yinghai.lu, kuznet, pekkas, jmorris, yoshfuji, kaber,
" <netdev
In-Reply-To: <4BC70EF1.6080400@cn.fujitsu.com>
Your netdev entry on the CC: list was literally:
" <netdev@vger.kernel.org>,
which caused your patch to not make it netdev and therefore
it also didn't make it into patchwork.
Please resubmit your patches (both of them) with the CC:
list fixed up.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] net/l2tp/l2tp_debugfs.c: Convert NIPQUAD to %pI4
From: David Miller @ 2010-04-15 22:37 UTC (permalink / raw)
To: jchapman; +Cc: joe, linux-kernel, netdev
In-Reply-To: <4BC75EA3.2070402@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Thu, 15 Apr 2010 19:44:51 +0100
> Joe Perches wrote:
>> Signed-off-by: Joe Perches <joe@perches.com>
> Acked-by: James Chapman <jchapman@katalix.com>
Applied, thanks.
^ permalink raw reply
* Re: rps perfomance WAS(Re: rps: question
From: Changli Gao @ 2010-04-15 23:51 UTC (permalink / raw)
To: hadi; +Cc: Eric Dumazet, Tom Herbert, netdev
In-Reply-To: <1271335844.23780.8.camel@bigi>
On Thu, Apr 15, 2010 at 8:50 PM, jamal <hadi@cyberus.ca> wrote:
> On Thu, 2010-04-15 at 20:32 +0800, Changli Gao wrote:
>
>> For historical reason, we use Linux-2.6.18. Our company have several
>> products with CPU Xen, P4, or i7. Some of them are SMP, Multi-Core and
>> Multi-Threaded.
>
> Thanks for sharing. How much more can you say? ;-> Do you have a paper
> or description of some sort somewhere?
On a dual 4-core Xeon, we use one core for NIC in internal side, one
core for NIC in the external side, one for inbound QoS, one for
outbound QoS, and the CPU cycles left are used by DPI(DFA), the total
throughput is about 3 Gbps with a polygraph test.
>
>> We use the similar mechanism like dynamic weighted
>> RPS. The total throughput is increased nearly linear with the number
>> of the worker threads(one worker thread per CPU).
>
> Other than the i7 - have you tried to run rps on on the P4?
>
No.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: rps perfomance WAS(Re: rps: question
From: Changli Gao @ 2010-04-15 23:56 UTC (permalink / raw)
To: hadi; +Cc: Rick Jones, David Miller, eric.dumazet, therbert, netdev, robert,
andi
In-Reply-To: <1271362581.23780.12.camel@bigi>
On Fri, Apr 16, 2010 at 4:16 AM, jamal <hadi@cyberus.ca> wrote:
>
> Sounds interesting.
> Wikipedia information overload. Any arch description of the HP9000?
> Did your scheme use IPIs to message the other CPUs?
>
If you doubt the cost of smp_call_function_single(), how about having
a try with my another patch, which implements the similar of RPS, but
uses kernel threads instead, so no explicit IPI.
http://patchwork.ozlabs.org/patch/38319/
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] ip: Fix ip_dev_loopback_xmit()
From: Changli Gao @ 2010-04-16 0:03 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, eparis, netdev, therbert
In-Reply-To: <20100415.142641.125242830.davem@davemloft.net>
On Fri, Apr 16, 2010 at 5:26 AM, David Miller <davem@davemloft.net> wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 15 Apr 2010 21:13:03 +0200
>
>> [PATCH] ip: Fix ip_dev_loopback_xmit()
>
> Applied to net-2.6, thanks Eric.
Now, I am doubting the correctness of the following comment:
/*
* The higher levels take care of making this non-reentrant (it's
* called with bh's disabled).
*/
static netdev_tx_t loopback_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct pcpu_lstats __percpu *pcpu_lstats;
struct pcpu_lstats *lb_stats;
int len;
skb_orphan(skb);
skb->protocol = eth_type_trans(skb, dev);
And these lines:
/* it's OK to use per_cpu_ptr() because BHs are off */
pcpu_lstats = (void __percpu __force *)dev->ml_priv;
lb_stats = this_cpu_ptr(pcpu_lstats);
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] ip: Fix ip_dev_loopback_xmit()
From: David Miller @ 2010-04-16 0:15 UTC (permalink / raw)
To: xiaosuo; +Cc: eric.dumazet, eparis, netdev, therbert
In-Reply-To: <w2o412e6f7f1004151703xdcc4da16s4eb6308f2578b531@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Fri, 16 Apr 2010 08:03:59 +0800
> On Fri, Apr 16, 2010 at 5:26 AM, David Miller <davem@davemloft.net> wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Thu, 15 Apr 2010 21:13:03 +0200
>>
>>> [PATCH] ip: Fix ip_dev_loopback_xmit()
>>
>> Applied to net-2.6, thanks Eric.
>
>
> Now, I am doubting the correctness of the following comment:
The ->hard_start_xmit() method always executes with software
interrupts disabled.
^ permalink raw reply
* Re: [PATCH] ip: Fix ip_dev_loopback_xmit()
From: Changli Gao @ 2010-04-16 0:19 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, eparis, netdev, therbert
In-Reply-To: <20100415.171548.179331927.davem@davemloft.net>
On Fri, Apr 16, 2010 at 8:15 AM, David Miller <davem@davemloft.net> wrote:
>
> The ->hard_start_xmit() method always executes with software
> interrupts disabled.
>
Oh, sorry. I traced to the wrong function.
--
Regards，
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: mac8390 - Sort out memory/MMIO accesses and casts (was: Re: drivers/net/mac8390.c: Remove useless memcpy casting)
From: Finn Thain @ 2010-04-16 2:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Joe Perches, David S. Miller, netdev, Linux Kernel Mailing List,
Linux/m68k
In-Reply-To: <l2k10f740e81004151234t3004275az36e7873493067a8a@mail.gmail.com>
On Thu, 15 Apr 2010, Geert Uytterhoeven wrote:
> On Mon, Mar 8, 2010 at 18:16, Joe Perches <joe@perches.com> wrote:
>
> > Thanks, I'll submit a patch to fix it by tomorrow or so.
>
> It hasn't been fixed yet.
Thanks for taking care of this, Geert.
> But here's a better solution. I do not have the hardware to test it,
> though. Finn, does it {look OK,work}?
It looks fine. I can't test it right now, but I will do so when I get the
opportunity.
Finn
^ permalink raw reply
* Re: [PATCH] rdma/cm: Randomize local port allocation.
From: Cong Wang @ 2010-04-16 2:22 UTC (permalink / raw)
To: Sean Hefty
Cc: 'Tetsuo Handa', opurdila, eric.dumazet, netdev, nhorman,
davem, ebiederm, linux-kernel, rolandd, linux-rdma
In-Reply-To: <5CE6BC7B954643FAAFFD2AD66F673CBD@amr.corp.intel.com>
Sean Hefty wrote:
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>
>> Randomize local port allocation in a way sctp_get_port_local() does.
>> Update rover at the end of loop since we're likely to pick a valid port
>> on the first try.
>>
>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Reviewed-by: Sean Hefty <sean.hefty@intel.com>
>
Thanks, everyone!
>
> I like this version, thanks! I'm not sure which tree to merge it through.
> Are you needing this for 2.6.34, or is 2.6.35 okay?
>
As soon as possible, so 2.6.34. :)
^ permalink raw reply
* Re: [net-next-2.6 PATCH 2/2] net: replace ipfragok with skb->local_df
From: Shan Wei @ 2010-04-16 2:26 UTC (permalink / raw)
To: Herbert Xu
Cc: David Miller, yinghai.lu, kuznet, pekkas, jmorris,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki,
Patrick McHardy, netdev@vger.kernel.org, dccp, linux-sctp,
kleptog, jchapman, mostrows, acme
In-Reply-To: <20100415151926.GA4813@gondor.apana.org.au>
Herbert Xu wrote, at 04/15/2010 11:19 PM:
> On Thu, Apr 15, 2010 at 09:04:49PM +0800, Shan Wei wrote:
>> As Herbert Xu said: we should be able to simply replace ipfragok
>> with skb->local_df. commit f88037(sctp: Drop ipfargok in sctp_xmit function)
>> has droped ipfragok and set local_df value properly.
>>
>> The patch kills the ipfragok parameter of .queue_xmit().
>
> Both patches look good to me.
>
>> @@ -370,7 +370,7 @@ packet_routed:
>> skb_reset_network_header(skb);
>> iph = ip_hdr(skb);
>> *((__be16 *)iph) = htons((4 << 12) | (5 << 8) | (inet->tos & 0xff));
>> - if (ip_dont_fragment(sk, &rt->u.dst) && !ipfragok)
>> + if (ip_dont_fragment(sk, &rt->u.dst) && !skb->local_df)
>> iph->frag_off = htons(IP_DF);
>> else
>> iph->frag_off = 0;
>
> This hunk looked suspecious at first. However, it is OK because
> ever calls this with ipfragok == 1, or local_df == 1.
>
> The first is obvious from this patch itself, the second not quite
> so obvious.
>
> As nobody calls it with local_df == 1 anyway, and strictly speaking
> local_df shouldn't be set at all by the caller of ip_queue_xmit, we
> should simply remove the && ... bit and have
>
> if (ip_dont_fragment(sk, &rt->u.dst))
Now, PPPoX/PPPoL2TP driver still use ip_queue_xmit to send packets with ipfragok == 1.
So, now we can't remove the && ... bit.
--
Best Regards
-----
Shan Wei
>
> Cheers,
^ permalink raw reply
* another cleanup patch gone wrong
From: Finn Thain @ 2010-04-16 2:34 UTC (permalink / raw)
To: Joe Perches
Cc: David S. Miller, Paul Gortmaker, netdev,
Linux Kernel Mailing List, Linux/m68k
...but this one was already merged, unfortunately.
> Use printk_once
> Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> Convert printks without KERN_<level> to pr_info and pr_cont
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
> diff --git a/drivers/net/mac8390.c b/drivers/net/mac8390.c
> index 517cee4..8bd09e2 100644 (file)
> --- a/drivers/net/mac8390.c
> +++ b/drivers/net/mac8390.c
> @@ -17,6 +17,8 @@
> /* 2002-12-30: Try to support more cards, some clues from NetBSD driver */
> /* 2003-12-26: Make sure Asante cards always work. */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
Why the macro? You only used it once.
The pr_xxx naming convention belongs to a kernel-wide include file. Is it
really a good idea to start repurposing it in .c files?
> @@ -545,7 +537,7 @@ static int __init mac8390_initdev(struct net_device * dev, struct nubus_dev * nd
> case MAC8390_APPLE:
> switch (mac8390_testio(dev->mem_start)) {
> case ACCESS_UNKNOWN:
> - printk("Don't know how to access card memory!\n");
> + pr_info("Don't know how to access card memory!\n");
No, this is pr_err. The driver sets dev->mem_start expecting it to work,
obviously.
> return -ENODEV;
> break;
>
> @@ -633,7 +626,7 @@ static int mac8390_open(struct net_device *dev)
> {
> __ei_open(dev);
> if (request_irq(dev->irq, __ei_interrupt, 0, "8390 Ethernet", dev)) {
> - printk ("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
> + pr_info("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
> return -EAGAIN;
Same here.
> }
> return 0;
> @@ -650,7 +643,7 @@ static void mac8390_no_reset(struct net_device *dev)
> {
> ei_status.txing = 0;
> if (ei_debug > 1)
> - printk("reset not supported\n");
> + pr_info("reset not supported\n");
I think you meant pr_debug().
> return;
> }
>
> @@ -658,11 +651,11 @@ static void interlan_reset(struct net_device *dev)
> {
> unsigned char *target=nubus_slot_addr(IRQ2SLOT(dev->irq));
> if (ei_debug > 1)
> - printk("Need to reset the NS8390 t=%lu...", jiffies);
> + pr_info("Need to reset the NS8390 t=%lu...", jiffies);
Same here.
Finn
^ permalink raw reply
* [net-next-2.6 PATCH 1/3 v2] ipv6: cancel to setting local_df in ip6_xmit()
From: Shan Wei @ 2010-04-16 2:39 UTC (permalink / raw)
To: David Miller, Herbert Xu, emils.tantilov
Cc: kuznet, pekkas, jmorris,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki,
Patrick McHardy, eric.dumazet, netdev@vger.kernel.org, Shan Wei
commit f88037(sctp: Drop ipfargok in sctp_xmit function)
has droped ipfragok and set local_df value properly.
So the change of commit 77e2f1(ipv6: Fix ip6_xmit to
send fragments if ipfragok is true) is not needed.
So the patch remove them.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
Resend the patches with fixed cc list, no content changes.
---
net/ipv6/ip6_output.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 16c4391..f3a847e 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -231,10 +231,6 @@ int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl,
skb_reset_network_header(skb);
hdr = ipv6_hdr(skb);
- /* Allow local fragmentation. */
- if (ipfragok)
- skb->local_df = 1;
-
/*
* Fill in the IPv6 header
*/
--
1.6.3.3
^ permalink raw reply related
* [net-next-2.6 PATCH 2/3 v2] net: replace ipfragok with skb->local_df
From: Shan Wei @ 2010-04-16 2:43 UTC (permalink / raw)
To: David Miller, Herbert Xu
Cc: Shan Wei, yinghai.lu, kuznet, pekkas, jmorris,
yoshfuji@linux-ipv6.org >> YOSHIFUJI Hideaki,
Patrick McHardy, netdev, dccp, linux-sctp, jchapman, mostrows
As Herbert Xu said: we should be able to simply replace ipfragok
with skb->local_df. commit f88037(sctp: Drop ipfargok in sctp_xmit function)
has droped ipfragok and set local_df value properly.
The patch kills the ipfragok parameter of .queue_xmit().
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
Resend the patches with fixed cc list, no content changes.
---
include/net/inet6_connection_sock.h | 2 +-
include/net/inet_connection_sock.h | 2 +-
include/net/ip.h | 2 +-
include/net/ipv6.h | 3 +--
net/dccp/ipv6.c | 4 ++--
net/dccp/output.c | 2 +-
net/ipv4/ip_output.c | 4 ++--
net/ipv4/tcp_output.c | 2 +-
net/ipv6/inet6_connection_sock.c | 4 ++--
net/ipv6/ip6_output.c | 2 +-
net/ipv6/tcp_ipv6.c | 4 ++--
net/l2tp/l2tp_core.c | 3 ++-
net/l2tp/l2tp_ip.c | 2 +-
net/sctp/ipv6.c | 2 +-
net/sctp/protocol.c | 2 +-
15 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/include/net/inet6_connection_sock.h b/include/net/inet6_connection_sock.h
index f13ddc2..aae08f6 100644
--- a/include/net/inet6_connection_sock.h
+++ b/include/net/inet6_connection_sock.h
@@ -38,5 +38,5 @@ extern void inet6_csk_reqsk_queue_hash_add(struct sock *sk,
extern void inet6_csk_addr2sockaddr(struct sock *sk, struct sockaddr *uaddr);
-extern int inet6_csk_xmit(struct sk_buff *skb, int ipfragok);
+extern int inet6_csk_xmit(struct sk_buff *skb);
#endif /* _INET6_CONNECTION_SOCK_H */
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index 52c8b8b..b6d3b55 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -36,7 +36,7 @@ struct tcp_congestion_ops;
* (i.e. things that depend on the address family)
*/
struct inet_connection_sock_af_ops {
- int (*queue_xmit)(struct sk_buff *skb, int ipfragok);
+ int (*queue_xmit)(struct sk_buff *skb);
void (*send_check)(struct sock *sk, struct sk_buff *skb);
int (*rebuild_header)(struct sock *sk);
int (*conn_request)(struct sock *sk, struct sk_buff *skb);
diff --git a/include/net/ip.h b/include/net/ip.h
index 503994a..a84ceb6 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -101,7 +101,7 @@ extern int ip_do_nat(struct sk_buff *skb);
extern void ip_send_check(struct iphdr *ip);
extern int __ip_local_out(struct sk_buff *skb);
extern int ip_local_out(struct sk_buff *skb);
-extern int ip_queue_xmit(struct sk_buff *skb, int ipfragok);
+extern int ip_queue_xmit(struct sk_buff *skb);
extern void ip_init(void);
extern int ip_append_data(struct sock *sk,
int getfrag(void *from, char *to, int offset, int len,
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 033ddd4..b1d8db9 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -482,8 +482,7 @@ extern int ip6_rcv_finish(struct sk_buff *skb);
extern int ip6_xmit(struct sock *sk,
struct sk_buff *skb,
struct flowi *fl,
- struct ipv6_txoptions *opt,
- int ipfragok);
+ struct ipv6_txoptions *opt);
extern int ip6_nd_hdr(struct sock *sk,
struct sk_buff *skb,
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index ab1ab95..0916988 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -292,7 +292,7 @@ static int dccp_v6_send_response(struct sock *sk, struct request_sock *req,
&ireq6->loc_addr,
&ireq6->rmt_addr);
ipv6_addr_copy(&fl.fl6_dst, &ireq6->rmt_addr);
- err = ip6_xmit(sk, skb, &fl, opt, 0);
+ err = ip6_xmit(sk, skb, &fl, opt);
err = net_xmit_eval(err);
}
@@ -347,7 +347,7 @@ static void dccp_v6_ctl_send_reset(struct sock *sk, struct sk_buff *rxskb)
if (!ip6_dst_lookup(ctl_sk, &dst, &fl)) {
if (xfrm_lookup(net, &dst, &fl, NULL, 0) >= 0) {
skb_dst_set(skb, dst);
- ip6_xmit(ctl_sk, skb, &fl, NULL, 0);
+ ip6_xmit(ctl_sk, skb, &fl, NULL);
DCCP_INC_STATS_BH(DCCP_MIB_OUTSEGS);
DCCP_INC_STATS_BH(DCCP_MIB_OUTRSTS);
return;
diff --git a/net/dccp/output.c b/net/dccp/output.c
index b8d98e3..e98b65e 100644
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -136,7 +136,7 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff *skb)
DCCP_INC_STATS(DCCP_MIB_OUTSEGS);
- err = icsk->icsk_af_ops->queue_xmit(skb, 0);
+ err = icsk->icsk_af_ops->queue_xmit(skb);
return net_xmit_eval(err);
}
return -ENOBUFS;
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index c65f18e..512af81 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -311,7 +311,7 @@ int ip_output(struct sk_buff *skb)
!(IPCB(skb)->flags & IPSKB_REROUTED));
}
-int ip_queue_xmit(struct sk_buff *skb, int ipfragok)
+int ip_queue_xmit(struct sk_buff *skb)
{
struct sock *sk = skb->sk;
struct inet_sock *inet = inet_sk(sk);
@@ -370,7 +370,7 @@ packet_routed:
skb_reset_network_header(skb);
iph = ip_hdr(skb);
*((__be16 *)iph) = htons((4 << 12) | (5 << 8) | (inet->tos & 0xff));
- if (ip_dont_fragment(sk, &rt->u.dst) && !ipfragok)
+ if (ip_dont_fragment(sk, &rt->u.dst) && !skb->local_df)
iph->frag_off = htons(IP_DF);
else
iph->frag_off = 0;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index e468499..2b7d71f 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -890,7 +890,7 @@ static int tcp_transmit_skb(struct sock *sk, struct sk_buff *skb, int clone_it,
if (after(tcb->end_seq, tp->snd_nxt) || tcb->seq == tcb->end_seq)
TCP_INC_STATS(sock_net(sk), TCP_MIB_OUTSEGS);
- err = icsk->icsk_af_ops->queue_xmit(skb, 0);
+ err = icsk->icsk_af_ops->queue_xmit(skb);
if (likely(err <= 0))
return err;
diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c
index 628db24..0c5e3c3 100644
--- a/net/ipv6/inet6_connection_sock.c
+++ b/net/ipv6/inet6_connection_sock.c
@@ -178,7 +178,7 @@ struct dst_entry *__inet6_csk_dst_check(struct sock *sk, u32 cookie)
return dst;
}
-int inet6_csk_xmit(struct sk_buff *skb, int ipfragok)
+int inet6_csk_xmit(struct sk_buff *skb)
{
struct sock *sk = skb->sk;
struct inet_sock *inet = inet_sk(sk);
@@ -234,7 +234,7 @@ int inet6_csk_xmit(struct sk_buff *skb, int ipfragok)
/* Restore final destination back after routing done */
ipv6_addr_copy(&fl.fl6_dst, &np->daddr);
- return ip6_xmit(sk, skb, &fl, np->opt, 0);
+ return ip6_xmit(sk, skb, &fl, np->opt);
}
EXPORT_SYMBOL_GPL(inet6_csk_xmit);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index f3a847e..141819f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -185,7 +185,7 @@ int ip6_output(struct sk_buff *skb)
*/
int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl,
- struct ipv6_txoptions *opt, int ipfragok)
+ struct ipv6_txoptions *opt)
{
struct net *net = sock_net(sk);
struct ipv6_pinfo *np = inet6_sk(sk);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index b429dfd..bd5ef7b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -509,7 +509,7 @@ static int tcp_v6_send_synack(struct sock *sk, struct request_sock *req,
__tcp_v6_send_check(skb, &treq->loc_addr, &treq->rmt_addr);
ipv6_addr_copy(&fl.fl6_dst, &treq->rmt_addr);
- err = ip6_xmit(sk, skb, &fl, opt, 0);
+ err = ip6_xmit(sk, skb, &fl, opt);
err = net_xmit_eval(err);
}
@@ -1071,7 +1071,7 @@ static void tcp_v6_send_response(struct sk_buff *skb, u32 seq, u32 ack, u32 win,
if (!ip6_dst_lookup(ctl_sk, &dst, &fl)) {
if (xfrm_lookup(net, &dst, &fl, NULL, 0) >= 0) {
skb_dst_set(buff, dst);
- ip6_xmit(ctl_sk, buff, &fl, NULL, 0);
+ ip6_xmit(ctl_sk, buff, &fl, NULL);
TCP_INC_STATS_BH(net, TCP_MIB_OUTSEGS);
if (rst)
TCP_INC_STATS_BH(net, TCP_MIB_OUTRSTS);
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 98dfcce..ecc7aea 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -954,7 +954,8 @@ int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb, size_t dat
}
/* Queue the packet to IP for output */
- error = ip_queue_xmit(skb, 1);
+ skb->local_df = 1;
+ error = ip_queue_xmit(skb);
/* Update stats */
if (error >= 0) {
diff --git a/net/l2tp/l2tp_ip.c b/net/l2tp/l2tp_ip.c
index 75bf784..0852512 100644
--- a/net/l2tp/l2tp_ip.c
+++ b/net/l2tp/l2tp_ip.c
@@ -501,7 +501,7 @@ static int l2tp_ip_sendmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *m
skb_dst_set(skb, dst_clone(&rt->u.dst));
/* Queue the packet to IP for output */
- rc = ip_queue_xmit(skb, 0);
+ rc = ip_queue_xmit(skb);
error:
/* Update stats */
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index 14db568..7326891 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -232,7 +232,7 @@ static int sctp_v6_xmit(struct sk_buff *skb, struct sctp_transport *transport)
if (!(transport->param_flags & SPP_PMTUD_ENABLE))
skb->local_df = 1;
- return ip6_xmit(sk, skb, &fl, np->opt, 0);
+ return ip6_xmit(sk, skb, &fl, np->opt);
}
/* Returns the dst cache entry for the given source and destination ip
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index a56f98e..704298f 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -854,7 +854,7 @@ static inline int sctp_v4_xmit(struct sk_buff *skb,
IP_PMTUDISC_DO : IP_PMTUDISC_DONT;
SCTP_INC_STATS(SCTP_MIB_OUTSCTPPACKS);
- return ip_queue_xmit(skb, 0);
+ return ip_queue_xmit(skb);
}
static struct sctp_af sctp_af_inet;
--
1.6.3.3
^ permalink raw reply related
* [net-next-2.6 PATCH 3/3 v2] ipv6: fix the comment of ip6_xmit()
From: Shan Wei @ 2010-04-16 2:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
ip6_xmit() is used by upper transport protocol.
Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
---
net/ipv6/ip6_output.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 141819f..5129a16 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -181,7 +181,7 @@ int ip6_output(struct sk_buff *skb)
}
/*
- * xmit an sk_buff (used by TCP)
+ * xmit an sk_buff (used by TCP, SCTP and DCCP)
*/
int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl,
--
1.6.3.3
^ permalink raw reply related
* Re: another cleanup patch gone wrong
From: David Miller @ 2010-04-16 3:01 UTC (permalink / raw)
To: fthain; +Cc: joe, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <alpine.OSX.2.00.1004161214270.271@localhost>
From: Finn Thain <fthain@telegraphics.com.au>
Date: Fri, 16 Apr 2010 12:34:24 +1000 (EST)
>
> ...but this one was already merged, unfortunately.
>
>> Use printk_once
>> Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> Convert printks without KERN_<level> to pr_info and pr_cont
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>>
>> diff --git a/drivers/net/mac8390.c b/drivers/net/mac8390.c
>> index 517cee4..8bd09e2 100644 (file)
>> --- a/drivers/net/mac8390.c
>> +++ b/drivers/net/mac8390.c
>> @@ -17,6 +17,8 @@
>> /* 2002-12-30: Try to support more cards, some clues from NetBSD driver */
>> /* 2003-12-26: Make sure Asante cards always work. */
>>
>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> +
>
> Why the macro? You only used it once.
It gets expanded internally into all of the pr_*() calls.
> The pr_xxx naming convention belongs to a kernel-wide include file. Is it
> really a good idea to start repurposing it in .c files?
This is exactly how it can be used, and there is much
precedent for this now.
>> - printk("Don't know how to access card memory!\n");
>> + pr_info("Don't know how to access card memory!\n");
>
> No, this is pr_err. The driver sets dev->mem_start expecting it to work,
> obviously.
It was an unspecified printk() so Joe's conversion is equal
and that's a good way for him to have made these changes.
If we want to mark this as KERN_ERR or whatever, that's entirely
a seperate change.
I think your objections to Joe's changes are completely uncalled
for and his changes were good ones.
^ permalink raw reply
* Re: another cleanup patch gone wrong
From: Joe Perches @ 2010-04-16 3:11 UTC (permalink / raw)
To: Finn Thain
Cc: David S. Miller, Paul Gortmaker, netdev,
Linux Kernel Mailing List, Linux/m68k
In-Reply-To: <alpine.OSX.2.00.1004161214270.271@localhost>
On Fri, 2010-04-16 at 12:34 +1000, Finn Thain wrote:
> ...but this one was already merged, unfortunately.
>
> > Use printk_once
> > Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > Convert printks without KERN_<level> to pr_info and pr_cont
> >
> > Signed-off-by: Joe Perches <joe@perches.com>
> > Signed-off-by: David S. Miller <davem@davemloft.net>
> >
> >
> > diff --git a/drivers/net/mac8390.c b/drivers/net/mac8390.c
> > index 517cee4..8bd09e2 100644 (file)
> > --- a/drivers/net/mac8390.c
> > +++ b/drivers/net/mac8390.c
> > @@ -17,6 +17,8 @@
> > /* 2002-12-30: Try to support more cards, some clues from NetBSD driver */
> > /* 2003-12-26: Make sure Asante cards always work. */
> >
> > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > +
>
> Why the macro? You only used it once.
It's used embedded in the pr_<level> functions.
It's used more than once.
> The pr_xxx naming convention belongs to a kernel-wide include file. Is it
> really a good idea to start repurposing it in .c files?
It's in kernel.h, and yes, it is.
http://lkml.org/lkml/2008/11/12/297
> No, this is pr_err. The driver sets dev->mem_start expecting it to work,
> obviously.
I suggest you change the levels to what you desire.
You could add yourself to the MAINTAINERS entry for this file.
cheers, Joe
^ permalink raw reply
* Re: another cleanup patch gone wrong
From: Finn Thain @ 2010-04-16 3:21 UTC (permalink / raw)
To: Joe Perches
Cc: David S. Miller, Paul Gortmaker, netdev,
Linux Kernel Mailing List, Linux/m68k
In-Reply-To: <1271387506.2298.17.camel@Joe-Laptop.home>
On Thu, 15 Apr 2010, Joe Perches wrote:
> > Why the macro? You only used it once.
>
> It's used embedded in the pr_<level> functions.
> It's used more than once.
>
> > The pr_xxx naming convention belongs to a kernel-wide include file. Is it
> > really a good idea to start repurposing it in .c files?
>
> It's in kernel.h, and yes, it is.
> http://lkml.org/lkml/2008/11/12/297
My mistake.
Finn
^ permalink raw reply
* [PATCH] mac8390: fix pr_info() calls, was Re: another cleanup patch gone wrong
From: Finn Thain @ 2010-04-16 3:45 UTC (permalink / raw)
To: David Miller; +Cc: joe, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <20100415.200113.215578006.davem@davemloft.net>
On Thu, 15 Apr 2010, David Miller wrote:
> >> - printk("Don't know how to access card memory!\n");
> >> + pr_info("Don't know how to access card memory!\n");
> >
> > No, this is pr_err. The driver sets dev->mem_start expecting it to work,
> > obviously.
>
> It was an unspecified printk() so Joe's conversion is equal
> and that's a good way for him to have made these changes.
Seems to me that the code went from unspecified to wrong. But I can see
your point of view.
> If we want to mark this as KERN_ERR or whatever, that's entirely a
> seperate change.
>
> I think your objections to Joe's changes are completely uncalled for and
> his changes were good ones.
Here's a patch, both uncalled-for and untested.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
--- a/drivers/net/mac8390.c 2010-04-16 13:31:04.000000000 +1000
+++ b/drivers/net/mac8390.c 2010-04-16 13:35:06.000000000 +1000
@@ -554,7 +554,7 @@
case MAC8390_APPLE:
switch (mac8390_testio(dev->mem_start)) {
case ACCESS_UNKNOWN:
- pr_info("Don't know how to access card memory!\n");
+ pr_err("Don't know how to access card memory!\n");
return -ENODEV;
break;
@@ -643,8 +643,8 @@
{
__ei_open(dev);
if (request_irq(dev->irq, __ei_interrupt, 0, "8390 Ethernet", dev)) {
- pr_info("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
- return -EAGAIN;
+ pr_err("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
+ return -EBUSY;
}
return 0;
}
@@ -660,7 +660,7 @@
{
ei_status.txing = 0;
if (ei_debug > 1)
- pr_info("reset not supported\n");
+ pr_debug("reset not supported\n");
return;
}
@@ -668,7 +668,7 @@
{
unsigned char *target = nubus_slot_addr(IRQ2SLOT(dev->irq));
if (ei_debug > 1)
- pr_info("Need to reset the NS8390 t=%lu...", jiffies);
+ pr_debug("Need to reset the NS8390 t=%lu...", jiffies);
ei_status.txing = 0;
target[0xC0000] = 0;
if (ei_debug > 1)
^ permalink raw reply
* Re: Network multiqueue question
From: George B. @ 2010-04-16 3:54 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <21433.1271354986@death.nxdomain.ibm.com>
On Thu, Apr 15, 2010 at 11:09 AM, Jay Vosburgh <fubar@us.ibm.com> wrote:
> The question I have about it (and the above patch), is: what
> does multi-queue "awareness" really mean for a bonding device? How does
> allocating a bunch of TX queues help, given that the determination of
> the transmitting device hasn't necessarily been made?
Good point.
> I haven't had the chance to acquire some multi-queue network
> cards and check things out with bonding, so I'm not really sure how it
> should work. Should the bond look, from a multi-queue perspective, like
> the largest slave, or should it look like the sum of the slaves? Some
> of this is may be mode-specific, as well.
I would say that having the number of bands be either the number of
cores or 4, whichever is the smaller would be a good start. That is
probably fine for GigE. Of the network cards we have that support
multiqueue, they are either 4 or 8 bands. In an optimal world, you
would have the number of bands that you have available at the physical
ethernet level but changing those on the fly in case of a change in
available interfaces might be more trouble than it is worth.
Four or eight would seem to be a good number to start with as I don't
think I have seen an ethernet card with less than 4. If you have
fewer than 4 CPUs there probably isn't much utility in having more
bands than processors, or maybe that utility rapidly diminishes as the
number of bands increases beyond the number of CPUs. At that point
you have probably just spent a lot of work building a bigger buffer.
I would be happy with 4 bands. I guess it just depends on where you
want the bottleneck. If you have 8 bands on the bond driver (another
reasonable alternative) and only 4 bands available for output, you
have just moved the contention down a layer to between the bond and
the ethernet driver. But I am a fan of moving the point of contention
as far away from the application interface as possible. If I have one
big lock around the bond driver and have 6 things waiting to talk to
the network, those are six things that can't be doing anything else.
I would rather have the application handle its network task and get
back to other things. Now if you have 8 bands of bond and only 4
bands of ethernet, or even one band of ethernet, oh well. Maybe have
1 to 8 bands configurable by an option to the driver that could be set
explicitly and defaults to, say, 4?
Thanks for taking the time to answer.
George
^ permalink raw reply
* Re: [PATCH] mac8390: fix pr_info() calls, was Re: another cleanup patch gone wrong
From: Joe Perches @ 2010-04-16 3:54 UTC (permalink / raw)
To: Finn Thain; +Cc: David Miller, p_gortmaker, netdev, linux-kernel, linux-m68k
In-Reply-To: <alpine.OSX.2.00.1004161323340.271@localhost>
On Fri, 2010-04-16 at 13:45 +1000, Finn Thain wrote:
> Here's a patch, both uncalled-for and untested.
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
>
> --- a/drivers/net/mac8390.c 2010-04-16 13:31:04.000000000 +1000
> +++ b/drivers/net/mac8390.c 2010-04-16 13:35:06.000000000 +1000
> @@ -643,8 +643,8 @@
> {
> __ei_open(dev);
> if (request_irq(dev->irq, __ei_interrupt, 0, "8390 Ethernet", dev)) {
> - pr_info("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
> - return -EAGAIN;
> + pr_err("%s: unable to get IRQ %d.\n", dev->name, dev->irq);
> + return -EBUSY;
You should document this in the changelog.
> }
> return 0;
> }
> @@ -660,7 +660,7 @@
> {
> ei_status.txing = 0;
> if (ei_debug > 1)
> - pr_info("reset not supported\n");
> + pr_debug("reset not supported\n");
You'll need to add
#define DEBUG
for this to print.
> - pr_info("Need to reset the NS8390 t=%lu...", jiffies);
> + pr_debug("Need to reset the NS8390 t=%lu...", jiffies);
This also now doesn't print.
cheers, Joe
^ 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