* Re: [PATCH net-next 03/10] net/bonding: Notify state change on slaves
From: Nikolay Aleksandrov @ 2015-02-03 16:09 UTC (permalink / raw)
To: Or Gerlitz, David S. Miller
Cc: netdev, Roland Dreier, Amir Vadai, Tal Alon, Moni Shoua
In-Reply-To: <1422974919-28084-4-git-send-email-ogerlitz@mellanox.com>
On 03/02/15 15:48, Or Gerlitz wrote:
> From: Moni Shoua <monis@mellanox.com>
>
> Use notifier chain to dispatch an event upon a change in slave state.
> Event is dispatched with slave specific info.
>
> Signed-off-by: Moni Shoua <monis@mellanox.com>
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> ---
> drivers/net/bonding/bond_main.c | 42 +++++++++++++++++++++++++++++++++++++++
> include/net/bonding.h | 12 +++++++++++
> 2 files changed, 54 insertions(+), 0 deletions(-)
>
Hi Or,
A few questions below,
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 0665608..c9771f3 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1191,6 +1191,47 @@ static void bond_fill_ifslave(struct slave *slave, struct ifslave *info)
> info->link_failure_count = slave->link_failure_count;
> }
>
> +static void bond_netdev_notify(struct slave *slave, struct net_device *dev)
> +{
> + struct bonding *bond = slave->bond;
^^^^^^^^^^^
What if the struct slave where "slave" points to gets freed before this execution ?
> + struct netdev_bonding_info bonding_info;
> +
> + rtnl_lock();
> + /* make sure that slave is still valid */
> + if (dev->priv_flags & IFF_BONDING) {
^^^^^^^
What if the slave is released, enslaved to a different bond and the old bond is
destroyed between the dereference up there and the rtnl_lock() ?
Or the bonding gets unloaded altogether ?
> + bond_fill_ifslave(slave, &bonding_info.slave);
> + bond_fill_ifbond(bond, &bonding_info.master);
> + netdev_bonding_info_change(slave->dev, &bonding_info);
> + }
> + rtnl_unlock();
> +}
> +
> +static void bond_netdev_notify_work(struct work_struct *_work)
> +{
> + struct netdev_notify_work *w =
> + container_of(_work, struct netdev_notify_work, work.work);
> +
> + bond_netdev_notify(w->slave, w->dev);
> + dev_put(w->dev);
> +}
> +
> +void bond_queue_slave_event(struct slave *slave)
> +{
> + struct netdev_notify_work *nnw = kzalloc(sizeof(*nnw), GFP_ATOMIC);
^^^^^^^^
Where's this freed after the work's done ?
> +
> + if (!nnw)
> + return;
> +
> + INIT_DELAYED_WORK(&nnw->work, bond_netdev_notify_work);
> + nnw->slave = slave;
> + nnw->dev = slave->dev;
> +
> + if (queue_delayed_work(slave->bond->wq, &nnw->work, 0))
> + dev_hold(slave->dev);
> + else
> + kfree(nnw);
> +}
> +
<snip>
Cheers,
Nik
^ permalink raw reply
* Re: [PATCH net-next] veth: set iflink to the peer veth
From: Eric Dumazet @ 2015-02-03 16:12 UTC (permalink / raw)
To: Nicolas Dichtel; +Cc: netdev, davem
In-Reply-To: <1422978106-4744-1-git-send-email-nicolas.dichtel@6wind.com>
On Tue, 2015-02-03 at 16:41 +0100, Nicolas Dichtel wrote:
> Now that the peer netns is advertised in rtnl messages, we can set this property
> so that IFLA_LINK will advertise the peer ifindex. It allows the userland to get
> the full veth configuration.
>
> Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
> ---
> drivers/net/veth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/veth.c b/drivers/net/veth.c
> index 4cca36ebc4fb..02d1f798a371 100644
> --- a/drivers/net/veth.c
> +++ b/drivers/net/veth.c
> @@ -427,9 +427,11 @@ static int veth_newlink(struct net *src_net, struct net_device *dev,
>
> priv = netdev_priv(dev);
> rcu_assign_pointer(priv->peer, peer);
> + dev->iflink = peer->ifindex;
>
> priv = netdev_priv(peer);
> rcu_assign_pointer(priv->peer, dev);
> + peer->iflink = dev->ifindex;
> return 0;
>
> err_register_dev:
Is is network namespace ready ?
If I move one veth to another namespace, is iflink still relevant ?
^ permalink raw reply
* Re: [PATCH net-next] veth: set iflink to the peer veth
From: Nicolas Dichtel @ 2015-02-03 16:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1422979929.907.19.camel@edumazet-glaptop2.roam.corp.google.com>
Le 03/02/2015 17:12, Eric Dumazet a écrit :
> If I move one veth to another namespace, is iflink still relevant ?
>
>
You're right. ifindex may change.
^ permalink raw reply
* Re: low vxlan throughput with tso enabled
From: Tom Herbert @ 2015-02-03 16:26 UTC (permalink / raw)
To: Reiner Herrmann; +Cc: Linux Netdev List, svens, Vittorio Curcio
In-Reply-To: <bde634e5-3c57-4e80-9309-670cbd51c1b9@DE-WIE-EXCH3A.green.sophos>
On Tue, Feb 3, 2015 at 7:50 AM, Reiner Herrmann
<reiner.herrmann@sophos.com> wrote:
> Hi!
>
> I have a vxlan tunnel established between two network interfaces, which
> both have a MTU of 1500. The vxlan interfaces have the same MTU.
> With TSO enabled, I observe low throughput with TCP connections (<100 kB/s).
> Disabling TSO works around this issue and throughput is as expected.
> Can someone please explain how TSO is influencing the tunnel to cause
> such a difference?
>
Please provide more information. What NIC? What is the link rate? What
are you running to test. Also report 'ethtool -k' of both tunnel and
Ethernet interfaces, and tcpdump on the interfaces (to see GSO
packets).
Thanks
> Kind regards,
> Reiner
>
> --
> 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
* Re: low vxlan throughput with tso enabled
From: Rick Jones @ 2015-02-03 16:36 UTC (permalink / raw)
To: Reiner Herrmann, netdev; +Cc: svens, Vittorio Curcio
In-Reply-To: <bde634e5-3c57-4e80-9309-670cbd51c1b9@DE-WIE-EXCH3A.green.sophos>
On 02/03/2015 07:50 AM, Reiner Herrmann wrote:
> I have a vxlan tunnel established between two network interfaces, which
> both have a MTU of 1500. The vxlan interfaces have the same MTU.
> With TSO enabled, I observe low throughput with TCP connections (<100
> kB/s).
> Disabling TSO works around this issue and throughput is as expected.
> Can someone please explain how TSO is influencing the tunnel to cause
> such a difference?
I've been under the impression that one generally wants the MTU of a
tunnel interface to be no more than the MTU of the physical interface
over which it runs, less the size of the encapsulation headers used by
the tunnel. What happens when you make the MTU of the tunnel interface
1400 bytes instead of 1500?
rick jones
^ permalink raw reply
* Re: [PATCH net-next] cxgb4: Add low latency socket busy_poll support
From: Rick Jones @ 2015-02-03 16:45 UTC (permalink / raw)
To: Hariprasad Shenai, netdev
Cc: davem, leedom, anish, nirranjan, praveenm, kumaras
In-Reply-To: <1422940816-27402-1-git-send-email-hariprasad@chelsio.com>
On 02/02/2015 09:20 PM, Hariprasad Shenai wrote:
> cxgb_busy_poll, corresponding to ndo_busy_poll, gets called by the socket
> waiting for data.
>
> With busy_poll enabled, improvement is seen in latency numbers as observed by
> collecting netperf TCP_RR numbers.
Which, not surprisingly, leads to the question - how much improvement?
:) Extra credit for including the change in netperf-reported service
demands.
happy benchmarking,
rick jones
^ permalink raw reply
* [PATCH net] pkt_sched: fq: avoid hang when quantum 0
From: Kenneth Klette Jonassen @ 2015-02-03 16:49 UTC (permalink / raw)
To: netdev; +Cc: Kenneth Klette Jonassen
Configuring fq with quantum 0 hangs the system, presumably because of a
non-interruptible infinite loop. Either way quantum 0 does not make sense.
Reproduce with:
sudo tc qdisc add dev lo root fq quantum 0 initial_quantum 0
ping 127.0.0.1
Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
---
net/sched/sch_fq.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 2a50f5c..313794b 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -670,8 +670,14 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
if (tb[TCA_FQ_FLOW_PLIMIT])
q->flow_plimit = nla_get_u32(tb[TCA_FQ_FLOW_PLIMIT]);
- if (tb[TCA_FQ_QUANTUM])
- q->quantum = nla_get_u32(tb[TCA_FQ_QUANTUM]);
+ if (tb[TCA_FQ_QUANTUM]) {
+ u32 quantum = nla_get_u32(tb[TCA_FQ_QUANTUM]);
+
+ if (quantum > 0)
+ q->quantum = quantum;
+ else
+ err = -EINVAL;
+ }
if (tb[TCA_FQ_INITIAL_QUANTUM])
q->initial_quantum = nla_get_u32(tb[TCA_FQ_INITIAL_QUANTUM]);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 03/10] net/bonding: Notify state change on slaves
From: Moni Shoua @ 2015-02-03 17:17 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Or Gerlitz, David S. Miller, netdev, Roland Dreier, Amir Vadai,
Tal Alon
In-Reply-To: <54D0F2B7.4000005@redhat.com>
> Hi Or,
> A few questions below,
>
Hi Nik
You are probably right about the problem of de-referencing slave
inside a work. I didn't think of the scenario of release the dev and
re-enslaving it to another bond while the work is still pending in the
queue.
I'll fix this and the memory leak you noticed in the next set
thanks
Moni
^ permalink raw reply
* Re: [PATCH 0/6 net-next] rhashtable fixes
From: Thomas Graf @ 2015-02-03 17:21 UTC (permalink / raw)
To: Ying Xue; +Cc: davem, netdev
In-Reply-To: <54CB5563.9080000@windriver.com>
On 01/30/15 at 05:56pm, Ying Xue wrote:
> On 01/30/2015 05:29 PM, Thomas Graf wrote:
> > Right, I see the same soft lockup. Interestingly I cannot trigger it
> > with the rht test code. I can only trigger it with your Netlink socket
> > creation stress test. It is definitely related to the deferred worker,
> > when I disable growing, then the bug disappears.
>
> Yes, when I disable expansion, the soft lockup also disappears too.
I have found the last remaining race and can now run your test
program successfully in an endless loop.
I will resubmit a v2 of this series.
^ permalink raw reply
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v2
From: Stephen Hemminger @ 2015-02-03 17:27 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, Hannes Frederic Sowa
In-Reply-To: <54D0124C.70202@gmail.com>
On Mon, 02 Feb 2015 17:11:56 -0700
David Ahern <dsahern@gmail.com> wrote:
> On 2/2/15 4:10 PM, Stephen Hemminger wrote:
> > Checkpatch complains about space before tab, which could be your
> > mailer mangling the patch.
>
> Yes, found that a couple of days ago. I use 'git send-email' to send the
> patches, and I have a pre-commit hook to run checkpatch.pl. Perhaps I
> goofed something in the recent latptop transitions.
>
> >
> > This should probably go into the netconf netlink message as well.
> >
>
> Not sure I understand this point. Can you point me to a code reference
> to look up?
>
> Though that did remind me that I should add a blurb in
> Documentation/networking/ip-sysctl.txt.
>
> David
Never mind, actually NETCONFA stuff is mostly for case where
listener needs to know how to handle offload, and this doesn't
impact that.
^ permalink raw reply
* [PATCH v2 net-next] pkt_sched: fq: better control of DDOS traffic
From: Eric Dumazet @ 2015-02-03 17:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1422626772.21689.90.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
FQ has a fast path for skb attached to a socket, as it does not
have to compute a flow hash. But for other packets, FQ being non
stochastic means that hosts exposed to random Internet traffic
can allocate million of flows structure (104 bytes each) pretty
easily. Not only host can OOM, but lookup in RB trees can take
too much cpu and memory resources.
This patch adds a new attribute, orphan_mask, that is adding
possibility of having a stochastic hash for orphaned skb.
Its default value is 1024 slots, to mimic SFQ behavior.
Note: This does not apply to locally generated TCP traffic,
and no locally generated traffic will share a flow structure
with another perfect or stochastic flow.
This patch also handles the specific case of SYNACK messages:
They are attached to the listener socket, and therefore all map
to a single hash bucket. If listener have set SO_MAX_PACING_RATE,
hoping to have new accepted socket inherit this rate, SYNACK
might be paced and even dropped.
This is very similar to an internal patch Google have used more
than one year.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
v2: make the left shift in fq_classify.
net/sched/sch_fq.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 2a50f5c62070a81ae37d871aac2626555128fd38..c7dee59763454777e8bb2c028d932340b2ced5da 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -92,6 +92,7 @@ struct fq_sched_data {
u32 flow_refill_delay;
u32 flow_max_rate; /* optional max rate per flow */
u32 flow_plimit; /* max packets per flow */
+ u32 orphan_mask; /* mask for orphaned skb */
struct rb_root *fq_root;
u8 rate_enable;
u8 fq_trees_log;
@@ -222,11 +223,20 @@ static struct fq_flow *fq_classify(struct sk_buff *skb, struct fq_sched_data *q)
if (unlikely((skb->priority & TC_PRIO_MAX) == TC_PRIO_CONTROL))
return &q->internal;
- if (unlikely(!sk)) {
+ /* SYNACK messages are attached to a listener socket.
+ * 1) They are not part of a 'flow' yet
+ * 2) We do not want to rate limit them (eg SYNFLOOD attack),
+ * especially if the listener set SO_MAX_PACING_RATE
+ * 3) We pretend they are orphaned
+ */
+ if (!sk || sk->sk_state == TCP_LISTEN) {
+ unsigned long hash = skb_get_hash(skb) & q->orphan_mask;
+
/* By forcing low order bit to 1, we make sure to not
* collide with a local flow (socket pointers are word aligned)
*/
- sk = (struct sock *)(skb_get_hash(skb) | 1L);
+ sk = (struct sock *)((hash << 1) | 1UL);
+ skb_orphan(skb);
}
root = &q->fq_root[hash_32((u32)(long)sk, q->fq_trees_log)];
@@ -698,6 +708,9 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
q->flow_refill_delay = usecs_to_jiffies(usecs_delay);
}
+ if (tb[TCA_FQ_ORPHAN_MASK])
+ q->orphan_mask = nla_get_u32(tb[TCA_FQ_ORPHAN_MASK]);
+
if (!err) {
sch_tree_unlock(sch);
err = fq_resize(sch, fq_log);
@@ -743,6 +756,7 @@ static int fq_init(struct Qdisc *sch, struct nlattr *opt)
q->delayed = RB_ROOT;
q->fq_root = NULL;
q->fq_trees_log = ilog2(1024);
+ q->orphan_mask = 1024 - 1;
qdisc_watchdog_init(&q->watchdog, sch);
if (opt)
@@ -772,6 +786,7 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
nla_put_u32(skb, TCA_FQ_FLOW_REFILL_DELAY,
jiffies_to_usecs(q->flow_refill_delay)) ||
+ nla_put_u32(skb, TCA_FQ_ORPHAN_MASK, q->orphan_mask) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
^ permalink raw reply related
* [PATCH net 0/1] Re: RFC: Fix "tc filter show" for basic filters
From: Ignacy Gawędzki @ 2015-02-03 17:32 UTC (permalink / raw)
To: netdev
In-Reply-To: <20150203141059.GA25454@zenon.in.qult.net>
Hi again,
After some playing around, I found that my quick-and-dirty fix didn't actually
do the job. I eventually traced the problem to come from the fact that
tcf_exts_dump_stats() just assumed that the list of actions in exts->actions
contains at least one element and accessed it using tcf_exts_first_act().
This is clearly not true in the case of filters with no associated action in
particular, as in the case of my "basic" filter.
Simply ensuring that the list is not empty beforehand is enough to fix the
problem, just as is also done above in tcf_exts_dump().
Ignacy Gawędzki (1):
cls_api.c: Fix dumping of non-existing actions' stats.
net/sched/cls_api.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--
2.1.0
^ permalink raw reply
* [PATCH net 1/1] cls_api.c: Fix dumping of non-existing actions' stats.
From: Ignacy Gawędzki @ 2015-02-03 17:32 UTC (permalink / raw)
To: netdev
In-Reply-To: <20150203141059.GA25454@zenon.in.qult.net>
In tcf_exts_dump_stats(), ensure that exts->actions is not empty before
accessing the first element of that list and calling tcf_action_copy_stats()
on it. This fixes some random segvs when adding filters of type "basic" with
no particular action.
This also fixes the dumping of those "no-action" filters, which more often
than not made calls to tcf_action_copy_stats() fail and consequently netlink
attributes added by the caller to be removed by a call to nla_nest_cancel().
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
---
net/sched/cls_api.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index aad6a67..30e6967 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -602,9 +602,12 @@ EXPORT_SYMBOL(tcf_exts_dump);
int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts)
{
#ifdef CONFIG_NET_CLS_ACT
- struct tc_action *a = tcf_exts_first_act(exts);
- if (tcf_action_copy_stats(skb, a, 1) < 0)
- return -1;
+ struct tc_action *a;
+ if (!list_empty(&exts->actions)) {
+ a = tcf_exts_first_act(exts);
+ if (tcf_action_copy_stats(skb, a, 1) < 0)
+ return -1;
+ }
#endif
return 0;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net 1/1] cls_api.c: Fix dumping of non-existing actions' stats.
From: Cong Wang @ 2015-02-03 17:39 UTC (permalink / raw)
To: Ignacy Gawędzki, netdev
In-Reply-To: <20150203173251.GB6246@zenon.in.qult.net>
On Tue, Feb 3, 2015 at 9:32 AM, Ignacy Gawędzki
<ignacy.gawedzki@green-communications.fr> wrote:
> In tcf_exts_dump_stats(), ensure that exts->actions is not empty before
> accessing the first element of that list and calling tcf_action_copy_stats()
> on it. This fixes some random segvs when adding filters of type "basic" with
> no particular action.
>
> This also fixes the dumping of those "no-action" filters, which more often
> than not made calls to tcf_action_copy_stats() fail and consequently netlink
> attributes added by the caller to be removed by a call to nla_nest_cancel().
>
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
> ---
> net/sched/cls_api.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index aad6a67..30e6967 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -602,9 +602,12 @@ EXPORT_SYMBOL(tcf_exts_dump);
> int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts)
> {
> #ifdef CONFIG_NET_CLS_ACT
> - struct tc_action *a = tcf_exts_first_act(exts);
> - if (tcf_action_copy_stats(skb, a, 1) < 0)
> - return -1;
> + struct tc_action *a;
> + if (!list_empty(&exts->actions)) {
> + a = tcf_exts_first_act(exts);
> + if (tcf_action_copy_stats(skb, a, 1) < 0)
> + return -1;
> + }
Hmm, or just fix tcf_exts_first_act()? Let it call list_first_entry_or_null().
Also, please add Fixes: tag.
Fixes: commit 33be627159913b094bb578e83e9a7fdc66c10208
^ permalink raw reply
* Re: [PATCH net] pkt_sched: fq: avoid hang when quantum 0
From: Eric Dumazet @ 2015-02-03 17:46 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev
In-Reply-To: <1422982158-12530-1-git-send-email-kennetkl@ifi.uio.no>
On Tue, 2015-02-03 at 17:49 +0100, Kenneth Klette Jonassen wrote:
> Configuring fq with quantum 0 hangs the system, presumably because of a
> non-interruptible infinite loop. Either way quantum 0 does not make sense.
>
> Reproduce with:
> sudo tc qdisc add dev lo root fq quantum 0 initial_quantum 0
> ping 127.0.0.1
>
> Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
> ---
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net 1/1] cls_api.c: Fix dumping of non-existing actions' stats.
From: Eric Dumazet @ 2015-02-03 17:51 UTC (permalink / raw)
To: Cong Wang; +Cc: Ignacy Gawędzki, netdev
In-Reply-To: <CAHA+R7Pq6aUyCzc2HE+b4RU0RfYnM_cLPfRcV3jLmAZ+dFCsxw@mail.gmail.com>
On Tue, 2015-02-03 at 09:39 -0800, Cong Wang wrote:
> Also, please add Fixes: tag.
>
> Fixes: commit 33be627159913b094bb578e83e9a7fdc66c10208
Or more exactly use this format for Fixes tag :
Fixes: 33be62715991 ("net_sched: act: use standard struct list_head")
(assuming this commit is indeed the one introducing the problem)
^ permalink raw reply
* [PATCH net v2] cls_api.c: Fix dumping of non-existing actions' stats.
From: Ignacy Gawędzki @ 2015-02-03 18:05 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAHA+R7Pq6aUyCzc2HE+b4RU0RfYnM_cLPfRcV3jLmAZ+dFCsxw@mail.gmail.com>
In tcf_exts_dump_stats(), ensure that exts->actions is not empty before
accessing the first element of that list and calling tcf_action_copy_stats()
on it. This fixes some random segvs when adding filters of type "basic" with
no particular action.
This also fixes the dumping of those "no-action" filters, which more often
than not made calls to tcf_action_copy_stats() fail and consequently netlink
attributes added by the caller to be removed by a call to nla_nest_cancel().
Fixes: 33be62715991 ("net_sched: act: use standard struct list_head")
Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
---
net/sched/cls_api.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
index aad6a67..baef987 100644
--- a/net/sched/cls_api.c
+++ b/net/sched/cls_api.c
@@ -556,8 +556,9 @@ void tcf_exts_change(struct tcf_proto *tp, struct tcf_exts *dst,
}
EXPORT_SYMBOL(tcf_exts_change);
-#define tcf_exts_first_act(ext) \
- list_first_entry(&(exts)->actions, struct tc_action, list)
+#define tcf_exts_first_act(ext) \
+ list_first_entry_or_null(&(exts)->actions, \
+ struct tc_action, list)
int tcf_exts_dump(struct sk_buff *skb, struct tcf_exts *exts)
{
@@ -603,7 +604,7 @@ int tcf_exts_dump_stats(struct sk_buff *skb, struct tcf_exts *exts)
{
#ifdef CONFIG_NET_CLS_ACT
struct tc_action *a = tcf_exts_first_act(exts);
- if (tcf_action_copy_stats(skb, a, 1) < 0)
+ if (a != NULL && tcf_action_copy_stats(skb, a, 1) < 0)
return -1;
#endif
return 0;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH net v2] cls_api.c: Fix dumping of non-existing actions' stats.
From: Cong Wang @ 2015-02-03 18:10 UTC (permalink / raw)
To: Ignacy Gawędzki, netdev
In-Reply-To: <20150203180518.GA3806@zenon.in.qult.net>
On Tue, Feb 3, 2015 at 10:05 AM, Ignacy Gawędzki
<ignacy.gawedzki@green-communications.fr> wrote:
> In tcf_exts_dump_stats(), ensure that exts->actions is not empty before
> accessing the first element of that list and calling tcf_action_copy_stats()
> on it. This fixes some random segvs when adding filters of type "basic" with
> no particular action.
>
> This also fixes the dumping of those "no-action" filters, which more often
> than not made calls to tcf_action_copy_stats() fail and consequently netlink
> attributes added by the caller to be removed by a call to nla_nest_cancel().
>
> Fixes: 33be62715991 ("net_sched: act: use standard struct list_head")
> Signed-off-by: Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr>
Acked-by: Cong Wang <cwang@twopensource.com>
Thanks!
^ permalink raw reply
* Re: Per-connection tcp_retries2 and RFC 1122 compliance
From: John Eckersberg @ 2015-02-03 18:11 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Netdev
In-Reply-To: <CADVnQymEvyJaM8ogia5kmARrrFF0dSk83iSUyPPTHOaCO+GrfQ@mail.gmail.com>
Neal Cardwell <ncardwell@google.com> writes:
> I believe the functionality you are looking for is the
> TCP_USER_TIMEOUT socket option:
I had tried that previously, and it did not help my case. The reason
why is that I was using a downstream kernel (Fedora 21, 3.17.8 in this
case) and it was missing this commit that went into 3.18:
commit b248230c34970a6c1c17c591d63b464e8d2cfc33
Author: Yuchung Cheng <ycheng@google.com>
Date: Mon Sep 29 13:20:38 2014 -0700
tcp: abort orphan sockets stalling on zero window probes
Currently we have two different policies for orphan sockets
that repeatedly stall on zero window ACKs. If a socket gets
a zero window ACK when it is transmitting data, the RTO is
used to probe the window. The socket is aborted after roughly
tcp_orphan_retries() retries (as in tcp_write_timeout()).
But if the socket was idle when it received the zero window ACK,
and later wants to send more data, we use the probe timer to
probe the window. If the receiver always returns zero window ACKs,
icsk_probes keeps getting reset in tcp_ack() and the orphan socket
can stall forever until the system reaches the orphan limit (as
commented in tcp_probe_timer()). This opens up a simple attack
to create lots of hanging orphan sockets to burn the memory
and the CPU, as demonstrated in the recent netdev post "TCP
connection will hang in FIN_WAIT1 after closing if zero window is
advertised." http://www.spinics.net/lists/netdev/msg296539.html
This patch follows the design in RTO-based probe: we abort an orphan
socket stalling on zero window when the probe timer reaches both
the maximum backoff and the maximum RTO. For example, an 100ms RTT
connection will timeout after roughly 153 seconds (0.3 + 0.6 +
.... + 76.8) if the receiver keeps the window shut. If the orphan
socket passes this check, but the system already has too many orphans
(as in tcp_out_of_resources()), we still abort it but we'll also
send an RST packet as the connection may still be active.
In addition, we change TCP_USER_TIMEOUT to cover (life or dead)
sockets stalled on zero-window probes. This changes the semantics
of TCP_USER_TIMEOUT slightly because it previously only applies
when the socket has pending transmission.
The key part being that last paragraph about stalled zero-window
probes. Here's the specific use case where I'm hitting this:
(1) Establish a TCP connection bound to a given IP address
(2) Remove IP address from host
(3) Write to socket
This gets kicked back by the IP layer as non-routable, which triggers
the same behavior as the zero-window probes.
The good news is, I confirmed this is working as expected when I tested
on 3.19.0-rc7.
Thanks for the pointer, I'll go take my harassment to the relevant
downstream folks.
^ permalink raw reply
* PROBLEM: Bnx2x Checksum/Length Error Over GRE Tunnel
From: Eren Türkay @ 2015-02-03 18:05 UTC (permalink / raw)
To: Network Development
In-Reply-To: <54D0A345.2030108@skyatlas.com>
[-- Attachment #1: Type: text/plain, Size: 11634 bytes --]
Hello,
I am having incorrect checksum and length calculation error when using
GRE tunnel and this leads to unstable/unreliable connections where even
simple nc connection cannot be made correctly due to a lot of TCP
retransmissions. The reported iperf output becomes 23Kbit/s.
When I disable tx checksumming with "ethtool -K eth0 tx off", the
problem seems to be solved but then I lose tcp segmentation offloading
support, without which adds an additional overhead on 10Gbit network
interface. With tx off, I get 4 to 7Gbit/s with parallel 40 connections
using iperf.
In tcpdump output (tcpdump -i em1 proto gre) when tx checksumming is
enabled, I see "checksum error" in every packet + "IP truncated-ip -
63631 bytes missing!" messages, and a lot of TCP
retransmissions. When tx is off, checksums are correct but I get 4-7Gbit
output. With GSO generalization code in [0] it is reported that
9.3Gbit/s is possible over GRE tunnel but I'm nowhere near these results.
Pcap file is attached when tx is on. I tried to contact the original
maintainers (broadcom) but I thought it would help to send it to netdev
mailing list as well.
Thank you for your time.
- Eren
[0] http://thread.gmane.org/gmane.linux.network/332194
Additional Information
======================
em1 is a 10G interface. Jumbo frames are enabled and MTU is set to 9000.
My GRE tunnel has 1500 MTU, and it is tunneled using em1.
Host OS: Ubuntu 14.04
Kernel: 3.18.0 (compiled from ubuntu-vivid repository)
Physical host: HP ProLiant BL460c G6
NIC: Broadcom Corporation NetXtreme II BCM57711E 10-Gigabit PCIe
Ethtool info:
driver: bnx2x
version: 1.710.51-0
firmware-version: bc 6.2.28 phy baa0.105
bus-info: 0000:02:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
ethtook -k em1:
Features for em1:
rx-checksumming: on
tx-checksumming: on
tx-checksum-ipv4: on
tx-checksum-ip-generic: off [fixed]
tx-checksum-ipv6: on
tx-checksum-fcoe-crc: off [fixed]
tx-checksum-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
rx-vlan-offload: on [fixed]
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: on
tx-ipip-segmentation: on
tx-sit-segmentation: on
tx-udp_tnl-segmentation: on
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
busy-poll: on [fixed]
./ver-linux:
Linux compute1vx 3.18.0-11-generic #12-Ubuntu SMP Wed Jan 28 18:16:44
EET 2015 x86_64 x86_64 x86_64 GNU/Linux
Gnu C 4.8
Gnu make 3.81
binutils 2.24
util-linux 2.20.1
mount support
module-init-tools 15
e2fsprogs 1.42.9
PPP 2.4.5
Linux C Library 2.19
Dynamic linker (ldd) 2.19
Procps 3.3.9
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.21
wireless-tools 30
Modules Loaded ip_gre ip_tunnel vhost_net vhost macvtap macvlan
nf_conntrack_ipv6 nf_defrag_ipv6 xt_mac xt_physdev br_netfilter xt_set
iptable_raw ip_set_hash_ip ip_set nfnetlink veth ipt_MASQUERADE
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4
xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc ip6table_filter
ip6_tables iptable_filter ip_tables ebtable_nat ebtables x_tables nbd
openvswitch geneve gre ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core
ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi gpio_ich
dm_multipath scsi_dh radeon intel_powerclamp coretemp kvm_intel kvm
crct10dif_pclmul crc32_pclmul ttm ghash_clmulni_intel drm_kms_helper
aesni_intel aes_x86_64 drm lrw gf128mul glue_helper ablk_helper
i7core_edac ipmi_si edac_core lpc_ich 8250_fintek cryptd hpilo hpwdt
i2c_algo_bit serio_raw ipmi_msghandler acpi_power_meter mac_hid lp
parport mlx4_en vxlan ip6_udp_tunnel udp_tunnel hid_generic bnx2x
psmouse usbhid ptp pps_core hid mdio mlx4_core hpsa libcrc32c
/proc/cpuinfo:
processor : 23
vendor_id : GenuineIntel
cpu family : 6
model : 44
model name : Intel(R) Xeon(R) CPU L5640 @ 2.27GHz
stepping : 2
microcode : 0x1a
cpu MHz : 1600.000
cache size : 12288 KB
physical id : 0
siblings : 12
core id : 1
cpu cores : 6
apicid : 3
initial apicid : 3
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2
popcnt aes lahf_lm ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid
bugs :
bogomips : 4533.56
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management:
/proc/modules:
ip_gre 18295 0 - Live 0xffffffffc05e7000
ip_tunnel 24254 1 ip_gre, Live 0xffffffffc05f3000
vhost_net 18104 1 - Live 0xffffffffc05ed000
vhost 29047 1 vhost_net, Live 0xffffffffc05de000
macvtap 18255 1 vhost_net, Live 0xffffffffc05d8000
macvlan 23656 1 macvtap, Live 0xffffffffc05cd000
nf_conntrack_ipv6 18894 4 - Live 0xffffffffc05c3000
nf_defrag_ipv6 34841 1 nf_conntrack_ipv6, Live 0xffffffffc05b5000
xt_mac 12492 1 - Live 0xffffffffc05b0000
xt_physdev 12587 10 - Live 0xffffffffc05ab000
br_netfilter 17878 1 xt_physdev, Live 0xffffffffc05a5000
xt_set 13314 1 - Live 0xffffffffc0596000
iptable_raw 12678 1 - Live 0xffffffffc0585000
ip_set_hash_ip 31394 1 - Live 0xffffffffc059c000
ip_set 41059 2 xt_set,ip_set_hash_ip, Live 0xffffffffc058a000
nfnetlink 14725 1 ip_set, Live 0xffffffffc0580000
veth 13376 0 - Live 0xffffffffc057b000
ipt_MASQUERADE 12678 3 - Live 0xffffffffc0576000
nf_nat_masquerade_ipv4 13412 1 ipt_MASQUERADE, Live 0xffffffffc0571000
iptable_nat 12875 1 - Live 0xffffffffc0567000
nf_nat_ipv4 14115 1 iptable_nat, Live 0xffffffffc056c000
nf_nat 22050 2 nf_nat_masquerade_ipv4,nf_nat_ipv4, Live 0xffffffffc0560000
nf_conntrack_ipv4 14806 6 - Live 0xffffffffc054f000
nf_defrag_ipv4 12758 1 nf_conntrack_ipv4, Live 0xffffffffc054a000
xt_conntrack 12760 9 - Live 0xffffffffc0557000
nf_conntrack 105074 6
nf_conntrack_ipv6,nf_nat_masquerade_ipv4,nf_nat_ipv4,nf_nat,nf_conntrack_ipv4,xt_conntrack,
Live 0xffffffffc052f000
ipt_REJECT 12541 2 - Live 0xffffffffc052a000
nf_reject_ipv4 13183 1 ipt_REJECT, Live 0xffffffffc0525000
xt_CHECKSUM 12549 1 - Live 0xffffffffc051b000
iptable_mangle 12695 1 - Live 0xffffffffc0516000
xt_tcpudp 12884 11 - Live 0xffffffffc0520000
bridge 108463 1 br_netfilter, Live 0xffffffffc04fa000
stp 12976 1 bridge, Live 0xffffffffc04f5000
llc 14396 2 bridge,stp, Live 0xffffffffc045d000
ip6table_filter 12815 1 - Live 0xffffffffc0430000
ip6_tables 27026 1 ip6table_filter, Live 0xffffffffc04e9000
iptable_filter 12810 1 - Live 0xffffffffc0334000
ip_tables 27240 4 iptable_raw,iptable_nat,iptable_mangle,iptable_filter,
Live 0xffffffffc044d000
ebtable_nat 12807 0 - Live 0xffffffffc024c000
ebtables 35009 1 ebtable_nat, Live 0xffffffffc0426000
x_tables 34059 15
xt_mac,xt_physdev,xt_set,iptable_raw,ipt_MASQUERADE,xt_conntrack,ipt_REJECT,xt_CHECKSUM,iptable_mangle,xt_tcpudp,ip6table_filter,ip6_tables,iptable_filter,ip_tables,ebtables,
Live 0xffffffffc0306000
nbd 17642 0 - Live 0xffffffffc0252000
openvswitch 79201 0 - Live 0xffffffffc04d4000
geneve 13338 1 openvswitch, Live 0xffffffffc0247000
[20/1876]
gre 13796 2 ip_gre,openvswitch, Live 0xffffffffc0293000
ib_iser 51896 0 - Live 0xffffffffc0418000
rdma_cm 43465 1 ib_iser, Live 0xffffffffc040c000
iw_cm 36940 1 rdma_cm, Live 0xffffffffc035c000
ib_cm 42689 1 rdma_cm, Live 0xffffffffc0350000
ib_sa 33950 2 rdma_cm,ib_cm, Live 0xffffffffc032a000
ib_mad 47486 2 ib_cm,ib_sa, Live 0xffffffffc02df000
ib_core 88311 6 ib_iser,rdma_cm,iw_cm,ib_cm,ib_sa,ib_mad, Live
0xffffffffc0313000
ib_addr 18923 2 rdma_cm,ib_core, Live 0xffffffffc02d9000
iscsi_tcp 18333 0 - Live 0xffffffffc0280000
libiscsi_tcp 25146 1 iscsi_tcp, Live 0xffffffffc02a4000
libiscsi 57233 3 ib_iser,iscsi_tcp,libiscsi_tcp, Live 0xffffffffc02f3000
scsi_transport_iscsi 99909 4 ib_iser,iscsi_tcp,libiscsi, Live
0xffffffffc02bf000
gpio_ich 13586 0 - Live 0xffffffffc036a000
dm_multipath 22843 0 - Live 0xffffffffc02ec000
scsi_dh 14882 1 dm_multipath, Live 0xffffffffc028e000
radeon 1552388 1 - Live 0xffffffffc067b000
intel_powerclamp 18823 0 - Live 0xffffffffc0675000
coretemp 13441 0 - Live 0xffffffffc0173000
kvm_intel 148362 4 - Live 0xffffffffc0a54000
kvm 462696 1 kvm_intel, Live 0xffffffffc0462000
crct10dif_pclmul 14307 0 - Live 0xffffffffc0178000
crc32_pclmul 13133 0 - Live 0xffffffffc0458000
ttm 85166 1 radeon, Live 0xffffffffc0437000
ghash_clmulni_intel 13230 0 - Live 0xffffffffc011a000
drm_kms_helper 98431 1 radeon, Live 0xffffffffc03be000
aesni_intel 169590 0 - Live 0xffffffffc03e1000
aes_x86_64 17131 1 aesni_intel, Live 0xffffffffc03db000
drm 317626 4 radeon,ttm,drm_kms_helper, Live 0xffffffffc036f000
lrw 13286 1 aesni_intel, Live 0xffffffffc02ba000
gf128mul 14951 1 lrw, Live 0xffffffffc033b000
glue_helper 13990 1 aesni_intel, Live 0xffffffffc0289000
ablk_helper 13597 1 aesni_intel, Live 0xffffffffc02b5000
i7core_edac 24139 0 - Live 0xffffffffc029d000
ipmi_si 53386 0 - Live 0xffffffffc0341000
edac_core 51908 2 i7core_edac, Live 0xffffffffc025b000
lpc_ich 21093 0 - Live 0xffffffffc0269000
8250_fintek 12925 0 - Live 0xffffffffc011f000
cryptd 20359 3 ghash_clmulni_intel,aesni_intel,ablk_helper, Live
0xffffffffc02af000
hpilo 17394 0 - Live 0xffffffffc027a000
hpwdt 14257 0 - Live 0xffffffffc0275000
i2c_algo_bit 13413 1 radeon, Live 0xffffffffc0270000
serio_raw 13483 0 - Live 0xffffffffc0298000
ipmi_msghandler 45318 1 ipmi_si, Live 0xffffffffc0147000
acpi_power_meter 18075 0 - Live 0xffffffffc00f0000
mac_hid 13227 0 - Live 0xffffffffc0081000
lp 17759 0 - Live 0xffffffffc0087000
parport 42348 1 lp, Live 0xffffffffc0075000
mlx4_en 90408 0 - Live 0xffffffffc022f000
vxlan 37128 2 openvswitch,mlx4_en, Live 0xffffffffc013c000
ip6_udp_tunnel 12755 2 geneve,vxlan, Live 0xffffffffc00e8000
udp_tunnel 13187 2 geneve,vxlan, Live 0xffffffffc00a5000
hid_generic 12559 0 - Live 0xffffffffc00f9000
bnx2x 722154 0 - Live 0xffffffffc017d000
psmouse 111586 0 - Live 0xffffffffc0156000
usbhid 52657 0 - Live 0xffffffffc012e000
ptp 19395 2 mlx4_en,bnx2x, Live 0xffffffffc0124000
pps_core 19382 1 ptp, Live 0xffffffffc006f000
hid 110426 2 hid_generic,usbhid, Live 0xffffffffc00fe000
mdio 13561 1 bnx2x, Live 0xffffffffc006a000
mlx4_core 245682 1 mlx4_en, Live 0xffffffffc00ab000
hpsa 81092 2 - Live 0xffffffffc0090000
libcrc32c 12644 2 openvswitch,bnx2x, Live 0xffffffffc0065000
--
System Administrator
https://skyatlas.com/
[-- Attachment #2: bnx2x-tx-on-netcat-connection.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 822 bytes --]
^ permalink raw reply
* [PATCH RFC] irda: condition with no effect
From: Nicholas Mc Guire @ 2015-02-03 18:34 UTC (permalink / raw)
To: Samuel Ortiz; +Cc: netdev, linux-kernel, Nicholas Mc Guire
The if and the else branch code are identical - so the condition has no
effect on the effective code - this patch removes the condition and the
duplicated code.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
As the if and else is functionally identical they could probably be
joined. From the comments it does seem that they might need to be
different cases - which could mean there is a bug here - someone that
knows the details of the drivers will need to check.
Joined the comments on the modes - which also might not be correct.
Note: this gives some warnings on CamelCase usage - but those are not
related to the proposed changes.
Patch was only compile tested for x86_64_defconfig + CONFIG_IRDA=m
CONFIG_VIA_FIR=m
Patch is against 3.19.0-rc7 (localversion-next = -next-20150203)
drivers/net/irda/via-ircc.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/net/irda/via-ircc.c b/drivers/net/irda/via-ircc.c
index 6960d4c..4005306 100644
--- a/drivers/net/irda/via-ircc.c
+++ b/drivers/net/irda/via-ircc.c
@@ -595,15 +595,10 @@ static void via_ircc_change_dongle_speed(int iobase, int speed,
InvertTX(iobase, OFF);
InvertRX(iobase, OFF);
SlowIRRXLowActive(iobase, OFF);
- if (IsSIROn(iobase)) { //sir
- EnGPIOtoRX2(iobase, OFF);
- WriteGIO(iobase, OFF);
- EnRX2(iobase, OFF); //sir to rx2
- } else { // fir mir
- EnGPIOtoRX2(iobase, OFF);
- WriteGIO(iobase, OFF);
- EnRX2(iobase, OFF); //fir to rx
- }
+ /* sir | fir | mir */
+ EnGPIOtoRX2(iobase, OFF);
+ WriteGIO(iobase, OFF);
+ EnRX2(iobase, OFF);
break;
case 0x11: /* Temic TFDS4500 */
--
1.7.10.4
^ permalink raw reply related
* Re: PROBLEM: Bnx2x Checksum/Length Error Over GRE Tunnel
From: Eric Dumazet @ 2015-02-03 18:46 UTC (permalink / raw)
To: Eren Türkay; +Cc: Network Development
In-Reply-To: <54D10DFE.1070604@skyatlas.com>
On Tue, 2015-02-03 at 20:05 +0200, Eren Türkay wrote:
> Hello,
>
> I am having incorrect checksum and length calculation error when using
> GRE tunnel and this leads to unstable/unreliable connections where even
> simple nc connection cannot be made correctly due to a lot of TCP
> retransmissions. The reported iperf output becomes 23Kbit/s.
>
> When I disable tx checksumming with "ethtool -K eth0 tx off", the
> problem seems to be solved but then I lose tcp segmentation offloading
> support, without which adds an additional overhead on 10Gbit network
> interface. With tx off, I get 4 to 7Gbit/s with parallel 40 connections
> using iperf.
>
> In tcpdump output (tcpdump -i em1 proto gre) when tx checksumming is
> enabled, I see "checksum error" in every packet + "IP truncated-ip -
> 63631 bytes missing!" messages, and a lot of TCP
> retransmissions. When tx is off, checksums are correct but I get 4-7Gbit
> output. With GSO generalization code in [0] it is reported that
> 9.3Gbit/s is possible over GRE tunnel but I'm nowhere near these results.
Strange, I am using bnx2x with no such problem.
Please note that tcpdump can display "checksum error" because it doesn't
always know the NIC will generate the checksums.
Can you please send : ifconfig -a, as I suspect an MTU issue
Here I easily reach line rate with a single flow.
ip tunnel add gre1 mode gre remote 10.246.11.52 local 10.246.11.51
ip link set gre1 up
ip addr add 7.7.8.51/24 dev gre1
lpk51:~# ip ro get 7.7.8.52
7.7.8.52 dev gre1 src 7.7.8.51
cache expires 557sec mtu 1476
lpk51:~# ./netperf -H 7.7.8.52 -Cc
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.8.52 () port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. 10^6bits/s % S % S us/KB us/KB
87380 16384 16384 10.00 9227.94 2.52 3.96 0.715 1.125
^ permalink raw reply
* [PATCH] IBM-EMAC: Delete an unnecessary check before the function call "of_dev_put"
From: SF Markus Elfring @ 2015-02-03 18:51 UTC (permalink / raw)
To: netdev; +Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Tue, 3 Feb 2015 19:47:33 +0100
The of_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ethernet/ibm/emac/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index 9388a83..162762d 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -2367,7 +2367,7 @@ static int emac_wait_deps(struct emac_instance *dev)
err = emac_check_deps(dev, deps) ? 0 : -ENODEV;
for (i = 0; i < EMAC_DEP_COUNT; i++) {
of_node_put(deps[i].node);
- if (err && deps[i].ofdev)
+ if (err)
of_dev_put(deps[i].ofdev);
}
if (err == 0) {
--
2.2.2
^ permalink raw reply related
* [PATCH] hyper-v: allow access to vmbus from userspace driver
From: Stephen Hemminger @ 2015-02-03 19:03 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang; +Cc: devel, netdev
Brocade is submitting a hyper-v driver for DPDK <dev@dpdk.org>
but this driver needs a hook in the hyper-v bus layer
to allow the additional hv_uio driver to access the shared vmbus
pages. The hv_uio driver lives in DPDK (like igb_uio) and provides
userspace access to raw network packets.
Signed-off-by: Stas Egorov <segorov@mirantis.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/hv/connection.c | 20 +++++++++++++++++---
include/linux/hyperv.h | 3 +++
2 files changed, 20 insertions(+), 3 deletions(-)
--- a/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
+++ b/drivers/hv/connection.c 2015-02-03 10:58:51.751752450 -0800
@@ -64,6 +64,21 @@ static __u32 vmbus_get_next_version(__u3
}
}
+static const uuid_le HV_NET_GUID = {
+ .b = {
+ 0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46,
+ 0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e
+ }
+};
+
+void vmbus_get_pages(unsigned long *int_page, unsigned long monitor_pages[2])
+{
+ *int_page = (unsigned long)vmbus_connection.int_page;
+ monitor_pages[0] = (unsigned long)vmbus_connection.monitor_pages[0];
+ monitor_pages[1] = (unsigned long)vmbus_connection.monitor_pages[1];
+}
+EXPORT_SYMBOL_GPL(vmbus_get_pages);
+
static int vmbus_negotiate_version(struct vmbus_channel_msginfo *msginfo,
__u32 version)
{
@@ -347,7 +362,8 @@ static void process_chn_event(u32 relid)
else
bytes_to_read = 0;
} while (read_state && (bytes_to_read != 0));
- } else {
+ } else if (!memcmp(&channel->device_obj->dev_type, &HV_NET_GUID,
+ sizeof(uuid_le))) {
pr_err("no channel callback for relid - %u\n", relid);
}
--- a/include/linux/hyperv.h 2015-02-03 10:58:51.751752450 -0800
+++ b/include/linux/hyperv.h 2015-02-03 10:58:51.751752450 -0800
@@ -868,6 +868,9 @@ extern int vmbus_recvpacket_raw(struct v
extern void vmbus_ontimer(unsigned long data);
+extern void vmbus_get_pages(unsigned long *int_page,
+ unsigned long monitor_pages[2]);
+
/* Base driver object */
struct hv_driver {
const char *name;
^ permalink raw reply
* [PATCH net] amd-xgbe: Adjust for zero-based traffic class count
From: Tom Lendacky @ 2015-02-03 18:49 UTC (permalink / raw)
To: netdev; +Cc: David Miller
The number of traffic classes reported by the hardware is zero-based
so increment the value returned to get an actual count.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
index 7bb5f07..1246140 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
@@ -552,13 +552,14 @@ void xgbe_get_all_hw_features(struct xgbe_prv_data *pdata)
break;
}
- /* The Queue and Channel counts are zero based so increment them
+ /* The Queue, Channel and TC counts are zero based so increment them
* to get the actual number
*/
hw_feat->rx_q_cnt++;
hw_feat->tx_q_cnt++;
hw_feat->rx_ch_cnt++;
hw_feat->tx_ch_cnt++;
+ hw_feat->tc_cnt++;
DBGPR("<--xgbe_get_all_hw_features\n");
}
^ permalink raw reply related
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