* [PATCH net-next] vxlan: Optimize vxlan rcv
From: Pravin B Shelar @ 2013-09-03 16:44 UTC (permalink / raw)
To: netdev; +Cc: stephen, Pravin B Shelar
vxlan-udp-recv function lookup vxlan_sock struct on every packet
recv by using udp-port number. we can use sk->sk_user_data to
store vxlan_sock and avoid lookup.
I have open coded rcu-api to store and read vxlan_sock from
sk_user_data to avoid sparse warning as sk_user_data is not
__rcu pointer.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
---
drivers/net/vxlan.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 6b560f3..7de131f 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -916,6 +916,8 @@ void vxlan_sock_release(struct vxlan_sock *vs)
spin_lock(&vn->sock_lock);
hlist_del_rcu(&vs->hlist);
+ smp_wmb();
+ vs->sock->sk->sk_user_data = NULL;
spin_unlock(&vn->sock_lock);
queue_work(vxlan_wq, &vs->del_work);
@@ -1009,7 +1011,8 @@ static int vxlan_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
port = inet_sk(sk)->inet_sport;
- vs = vxlan_find_sock(sock_net(sk), port);
+ smp_read_barrier_depends();
+ vs = (struct vxlan_sock *)sk->sk_user_data;
if (!vs)
goto drop;
@@ -2236,6 +2239,8 @@ static struct vxlan_sock *vxlan_socket_create(struct net *net, __be16 port,
atomic_set(&vs->refcnt, 1);
vs->rcv = rcv;
vs->data = data;
+ smp_wmb();
+ vs->sock->sk->sk_user_data = vs;
spin_lock(&vn->sock_lock);
hlist_add_head_rcu(&vs->hlist, vs_head(net, port));
--
1.7.1
^ permalink raw reply related
* RE: [patch] qlcnic: remove a stray semicolon
From: Himanshu Madhani @ 2013-09-03 16:43 UTC (permalink / raw)
To: Dan Carpenter
Cc: Rajesh Borundia, Shahed Shaikh, Jitendra Kalsaria, Sony Chacko,
Sucheta Chakraborty, Dept-Eng Linux Driver, netdev,
kernel-janitors@vger.kernel.org
In-Reply-To: <20130903091347.GA4630@elgon.mountain>
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Tuesday, September 03, 2013 2:14 AM
> To: Himanshu Madhani
> Cc: Rajesh Borundia; Shahed Shaikh; Jitendra Kalsaria; Sony Chacko; Sucheta
> Chakraborty; Dept-Eng Linux Driver; netdev; kernel-janitors@vger.kernel.org
> Subject: [patch] qlcnic: remove a stray semicolon
>
> Just remove a small semicolon.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> index 332aa71..4d7ad00 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> @@ -1709,7 +1709,7 @@ qlcnic_set_dump(struct net_device *netdev, struct
> ethtool_dump *val)
> qlcnic_dev_request_reset(adapter, val->flag);
> adapter->flags &= ~QLCNIC_FW_RESET_OWNER;
> break;
> -;
> +
> case QLCNIC_SET_QUIESCENT:
> case QLCNIC_RESET_QUIESCENT:
> state = QLC_SHARED_REG_RD32(adapter,
> QLCNIC_CRB_DEV_STATE);
Thanks
Acked-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
^ permalink raw reply
* [PATCH net-next] net: tcp_probe: adapt tbuf size for recent changes
From: Daniel Borkmann @ 2013-09-03 16:24 UTC (permalink / raw)
To: davem; +Cc: netdev
With recent changes in tcp_probe module (e.g. f925d0a62d ("net: tcp_probe:
add IPv6 support")) we also need to take into account that tbuf needs to
be updated as format string will be further expanded. tbuf sits on the stack
in tcpprobe_read() function that is invoked when user space reads procfs
file /proc/net/tcpprobe, hence not fast path as in jtcp_rcv_established().
Having a size similarly as in sctp_probe module of 256 bytes is fully
sufficient for that, we need theoretical maximum of 252 bytes otherwise we
could get truncated.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
net/ipv4/tcp_probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_probe.c b/net/ipv4/tcp_probe.c
index 622a437..1f6aa54 100644
--- a/net/ipv4/tcp_probe.c
+++ b/net/ipv4/tcp_probe.c
@@ -218,7 +218,7 @@ static ssize_t tcpprobe_read(struct file *file, char __user *buf,
return -EINVAL;
while (cnt < len) {
- char tbuf[164];
+ char tbuf[256];
int width;
/* Wait for data in buffer */
--
1.7.11.7
^ permalink raw reply related
* Re: BQL support in gianfar causes network hiccup
From: Claudiu Manoil @ 2013-09-03 16:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Per Dalén, netdev
In-Reply-To: <1378222940.7360.34.camel@edumazet-glaptop>
On 9/3/2013 6:42 PM, Eric Dumazet wrote:
> On Tue, 2013-09-03 at 09:55 +0200, Per Dalén wrote:
>
>> Yes, it's weird. The only reason I removed the BQL commit
>> (d8a0f1b0af67679bba886784de10d8c21acc4e0e) was because the error Tino
>> Keitel had was the similar as mine.
>
>
> I suspect a genuine race in this driver. BQL only makes this race happen
> more often.
>
> gfar_poll_sq() has the following :
>
> /* run Tx cleanup to completion */
> if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx])
> gfar_clean_tx_ring(tx_queue);
>
> While gfar_poll() has a different method :
>
> if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx]) {
> gfar_clean_tx_ring(tx_queue);
> has_tx_work = 1;
> }
>
> Note the has_tx_work use in gfar_poll() only.
>
> Note that memory barriers seems to be missing.
>
> 1) In your cases, is it gfar_poll_sq() or gfar_poll() that is used ?
>
It's gfar_poll_sq(). P2020 single Tx/Rx queues.
I'm also seeing carrier errors and packet collisions in this case
(100/Half link).
> 2) Is the bug happening if only one CPU is used ?
>
I didn't try this. Maybe Per did?
^ permalink raw reply
* RE: [PATCH net] bnx2x: bail out if unable to acquire stats_sema
From: Dmitry Kravkov @ 2013-09-03 15:51 UTC (permalink / raw)
To: Michal Schmidt, davem@davemloft.net
Cc: netdev@vger.kernel.org, Ariel Elior, Eilon Greenstein
In-Reply-To: <1378223159-8710-1-git-send-email-mschmidt@redhat.com>
> -----Original Message-----
> From: Michal Schmidt [mailto:mschmidt@redhat.com]
> Sent: Tuesday, September 03, 2013 6:46 PM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org; Dmitry Kravkov; Ariel Elior; Eilon Greenstein
> Subject: [PATCH net] bnx2x: bail out if unable to acquire stats_sema
>
> If we fail to acquire stats_sema in the specified time limit, the chip is
> probably dead. It probably does not matter whether we try to continue or
> not, but certainly we should not up() the semaphore afterwards.
>
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> ---
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 24
> +++++++++++++++++------
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
> b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
> index 86436c7..d60bb8b 100644
> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
> @@ -538,16 +538,20 @@ static void __bnx2x_stats_start(struct bnx2x *bp)
>
> static void bnx2x_stats_start(struct bnx2x *bp) {
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
> __bnx2x_stats_start(bp);
> up(&bp->stats_sema);
> }
>
> static void bnx2x_stats_pmf_start(struct bnx2x *bp) {
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
> bnx2x_stats_comp(bp);
> __bnx2x_stats_pmf_update(bp);
> __bnx2x_stats_start(bp);
> @@ -556,8 +560,10 @@ static void bnx2x_stats_pmf_start(struct bnx2x *bp)
>
> static void bnx2x_stats_pmf_update(struct bnx2x *bp) {
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
> __bnx2x_stats_pmf_update(bp);
> up(&bp->stats_sema);
> }
> @@ -569,8 +575,10 @@ static void bnx2x_stats_restart(struct bnx2x *bp)
> */
> if (IS_VF(bp))
> return;
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
> bnx2x_stats_comp(bp);
> __bnx2x_stats_start(bp);
> up(&bp->stats_sema);
> @@ -1361,8 +1369,10 @@ static void bnx2x_stats_stop(struct bnx2x *bp) {
> int update = 0;
>
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
>
> bp->stats_started = false;
>
> @@ -1997,8 +2007,10 @@ void bnx2x_afex_collect_stats(struct bnx2x *bp,
> void *void_afex_stats, void bnx2x_stats_safe_exec(struct bnx2x *bp,
> void (func_to_exec)(void *cookie),
> void *cookie){
> - if (down_timeout(&bp->stats_sema, HZ/10))
> + if (down_timeout(&bp->stats_sema, HZ/10)) {
> BNX2X_ERR("Unable to acquire stats lock\n");
> + return;
> + }
> bnx2x_stats_comp(bp);
> func_to_exec(cookie);
> __bnx2x_stats_start(bp);
> --
> 1.8.3.1
>
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
* Re: [PATCH iproute2] pkt_sched: fq: Fair Queue packet scheduler
From: Stephen Hemminger @ 2013-09-03 15:49 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, ycheng, ncardwell
In-Reply-To: <1377829836.8277.59.camel@edumazet-glaptop>
On Thu, 29 Aug 2013 19:30:36 -0700
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Support for FQ packet scheduler
Applied to net-next-3.11 branch, with some minor cleanups.
^ permalink raw reply
* [PATCH net] bnx2x: bail out if unable to acquire stats_sema
From: Michal Schmidt @ 2013-09-03 15:45 UTC (permalink / raw)
To: davem; +Cc: netdev, Dmitry Kravkov, Ariel Elior, Eilon Greenstein
If we fail to acquire stats_sema in the specified time limit,
the chip is probably dead. It probably does not matter whether we
try to continue or not, but certainly we should not up() the semaphore
afterwards.
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c | 24 +++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
index 86436c7..d60bb8b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
@@ -538,16 +538,20 @@ static void __bnx2x_stats_start(struct bnx2x *bp)
static void bnx2x_stats_start(struct bnx2x *bp)
{
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
__bnx2x_stats_start(bp);
up(&bp->stats_sema);
}
static void bnx2x_stats_pmf_start(struct bnx2x *bp)
{
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
bnx2x_stats_comp(bp);
__bnx2x_stats_pmf_update(bp);
__bnx2x_stats_start(bp);
@@ -556,8 +560,10 @@ static void bnx2x_stats_pmf_start(struct bnx2x *bp)
static void bnx2x_stats_pmf_update(struct bnx2x *bp)
{
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
__bnx2x_stats_pmf_update(bp);
up(&bp->stats_sema);
}
@@ -569,8 +575,10 @@ static void bnx2x_stats_restart(struct bnx2x *bp)
*/
if (IS_VF(bp))
return;
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
bnx2x_stats_comp(bp);
__bnx2x_stats_start(bp);
up(&bp->stats_sema);
@@ -1361,8 +1369,10 @@ static void bnx2x_stats_stop(struct bnx2x *bp)
{
int update = 0;
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
bp->stats_started = false;
@@ -1997,8 +2007,10 @@ void bnx2x_afex_collect_stats(struct bnx2x *bp, void *void_afex_stats,
void bnx2x_stats_safe_exec(struct bnx2x *bp,
void (func_to_exec)(void *cookie),
void *cookie){
- if (down_timeout(&bp->stats_sema, HZ/10))
+ if (down_timeout(&bp->stats_sema, HZ/10)) {
BNX2X_ERR("Unable to acquire stats lock\n");
+ return;
+ }
bnx2x_stats_comp(bp);
func_to_exec(cookie);
__bnx2x_stats_start(bp);
--
1.8.3.1
^ permalink raw reply related
* [PATCH RFC] solos-pci: Fix BUG() with shared skb
From: David Woodhouse @ 2013-09-03 15:45 UTC (permalink / raw)
To: netdev; +Cc: Simon Arlott, linux-atm-general, nathan
[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]
Simon reported this BUG():
kernel BUG at net/core/skbuff.c:1065!
Call Trace:
[<f9b7c12c>] ? pppoatm_send+0x3f/0x1a0 [pppoatm]
[<f8751797>] psend+0xa9/0x14a [solos_pci]
[<f9b7c248>] pppoatm_send+0x15b/0x1a0 [pppoatm]
[<f8a2f77d>] ppp_push+0x76/0x533 [ppp_generic]
(Rest of backtrace at http://s85.org/mn0aOxMN — the skb appears to be
IPv6, forwarded from another interface over PPPoATM.)
I wasn't expecting to see shared skbs in the ATM driver's ->send()
function. Is this the right fix?
I've included the whole function in the patch context... I appear to be
jumping through a lot of hand-coded hoops here, just to ensure that I
can safely prepend my own device's hardware header to the skb. This
makes me think that I'm doing something severely wrong. There ought to
be an easier way of doing this, surely? What am I missing?
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 32784d1..b15e475 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -1135,40 +1135,50 @@ static uint32_t fpga_tx(struct solos_card *card)
static int psend(struct atm_vcc *vcc, struct sk_buff *skb)
{
struct solos_card *card = vcc->dev->dev_data;
struct pkt_hdr *header;
int pktlen;
pktlen = skb->len;
if (pktlen > (BUF_SIZE - sizeof(*header))) {
dev_warn(&card->dev->dev, "Length of PDU is too large. Dropping PDU.\n");
solos_pop(vcc, skb);
return 0;
}
+ /* This is skb_share_check() except it uses solos_pop() instead of kfree_skb() */
+ if (skb_shared(skb)) {
+ struct sk_buff *nskb = skb_clone(skb, GFP_ATOMIC);
+ if (unlikely(!nskb)) {
+ solos_pop(vcc, skb);
+ return 0;
+ }
+ consume_skb(skb);
+ skb = nskb;
+ }
if (!skb_clone_writable(skb, sizeof(*header))) {
int expand_by = 0;
int ret;
if (skb_headroom(skb) < sizeof(*header))
expand_by = sizeof(*header) - skb_headroom(skb);
ret = pskb_expand_head(skb, expand_by, 0, GFP_ATOMIC);
if (ret) {
dev_warn(&card->dev->dev, "pskb_expand_head failed.\n");
solos_pop(vcc, skb);
return ret;
}
}
header = (void *)skb_push(skb, sizeof(*header));
/* This does _not_ include the size of the header */
header->size = cpu_to_le16(pktlen);
header->vpi = cpu_to_le16(vcc->vpi);
header->vci = cpu_to_le16(vcc->vci);
header->type = cpu_to_le16(PKT_DATA);
fpga_queue(card, SOLOS_CHAN(vcc->dev), skb, vcc);
return 0;
}
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5745 bytes --]
^ permalink raw reply related
* Re: BQL support in gianfar causes network hiccup
From: Eric Dumazet @ 2013-09-03 15:42 UTC (permalink / raw)
To: Per Dalén; +Cc: Claudiu Manoil, netdev
In-Reply-To: <522595DD.1030600@appeartv.com>
On Tue, 2013-09-03 at 09:55 +0200, Per Dalén wrote:
> Yes, it's weird. The only reason I removed the BQL commit
> (d8a0f1b0af67679bba886784de10d8c21acc4e0e) was because the error Tino
> Keitel had was the similar as mine.
I suspect a genuine race in this driver. BQL only makes this race happen
more often.
gfar_poll_sq() has the following :
/* run Tx cleanup to completion */
if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx])
gfar_clean_tx_ring(tx_queue);
While gfar_poll() has a different method :
if (tx_queue->tx_skbuff[tx_queue->skb_dirtytx]) {
gfar_clean_tx_ring(tx_queue);
has_tx_work = 1;
}
Note the has_tx_work use in gfar_poll() only.
Note that memory barriers seems to be missing.
1) In your cases, is it gfar_poll_sq() or gfar_poll() that is used ?
2) Is the bug happening if only one CPU is used ?
^ permalink raw reply
* Re: [PATCH v3] net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)
From: Arvid Brodin @ 2013-09-03 15:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, joe, jboticario, balferreira
In-Reply-To: <20130830.155415.1756229438072680437.davem@davemloft.net>
On 2013-08-30 21:54, David Miller wrote:
> From: Arvid Brodin <arvid.brodin@xdin.com>
> Date: Wed, 21 Aug 2013 20:20:17 +0200
>
>> This is a patch against net-next (2013-08-21).
>
> First of all, your email client corrupted the patch, chopping up long lines
> and making whitespace changes to the content of the patch. Please fix this
> before resubmitting, and do so by first sending a test patch to yourself
> and making sure you can apply the patch you receive in that email. Do not
> use attachments to deal with this issue.
Sorry about that - I forgot to disable Format=Flowed... :(
>> + if (dev->operstate != transition) {
>> + write_lock_bh(&dev_base_lock);
>> + dev->operstate = transition;
>> + write_unlock_bh(&dev_base_lock);
>> + netdev_state_change(dev);
>> + }
>
> This is racy. And it appears that set_operstate() in net/core/rtnetlink.c
> has the same bug, I guess that's what you used as a guide.
>
> Any "test and set" sequence must be guarded completely by the lock, it
> doesn't make any sense to only guard the change of the value.
I never did understand the purpose of the locking done in set_operstate(). Will fix.
Also, Stephen Hemminger told me to use rtnl_mutex instead, but when I pointed
to net/core/rtnetlink.c and asked if he was sure, I did not get a reply. This
function - __hsr_set_operstate() - is only called from a notifier_call function,
so rtnl_mutex is already held here. Do I even need additional locking?
(According to ULNI* pp 171 Stephen is right and net/core/rtnetlink.c is wrong...)
* ULNI = Understanding Linux Network Internals
--
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarnäsgatan 7 | SE-164 40 Kista | Sweden | xdin.com
^ permalink raw reply
* Re: [iproute2 PATCH] iproute2: linklayer interface between kernel and tc/userspace
From: Stephen Hemminger @ 2013-09-03 15:33 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20130830120210.1510.80733.stgit@localhost>
On Fri, 30 Aug 2013 14:02:10 +0200
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> This iproute2 tc patch is connected to the kernel
> - commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling)
>
> The rate table calculated by tc, have gotten replaced in the kernel
> and is no-longer used for lookups.
>
> This happened in kernel release v3.8 caused by kernel
> - commit 56b765b79 ("htb: improved accuracy at high rates").
> This change unfortunately caused breakage of tc overhead and
> linklayer parameters.
>
> Kernel overhead handling got fixed in kernel v3.10 by
> - commit 01cb71d2d47 (net_sched: restore "overhead xxx" handling)
>
> Kernel linklayer handling got fixed in kernel v3.11 by
> - commit 8a8e3d84b17 (net_sched: restore "linklayer atm" handling)
>
> The linklayer fix introduced a struct change, that allow the linklayer
> attribute to be transferred between tc and kernel. This patch make use
> of this linklayer attribute.
>
> The linklayer setting is transfer to the kernel. And linklayer
> setting received from the kernel is printed with a prefixed
> "linklayer" when listing current configuration. The default
> TC_LINKLAYER_ETHERNET is only printed in detailed output mode.
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Ok, Applied for 3.11
^ permalink raw reply
* [ANNOUNCE] iprotue2 v3.11.0
From: Stephen Hemminger @ 2013-09-03 15:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Iproute2 tools for Workgroups (3.11) is not available.
It has the usual set of fixes and support for the new features
in 3.11. Thank for all the contributions.
I will merge in the next-3.11 branch. After that
if you have been sitting on changes to iproute2 that are in
net-next for 3.12 merge window, please submit them now.
Iproute2 package is available at:
http://kernel.org/pub/linux/utils/net/iproute2/iproute2-3.10.0.tar.gz
You can download the source from:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git
---
Adam Borowski (1):
ip: fix build failure if time_t is not long int
Alexander Duyck (1):
iproute2: act_ipt fix xtables breakage on older versions.
Amerigo Wang (1):
iptunnel: check SIT_ISATAP flag only for SIT tunnel
Andreas Henriksson (1):
iproute2: fix build failure on sparc due to -Wformat and tv_usec
Andrey Vagin (5):
ip: set the close-on-exec flag for descriptors
ss: handle socket diag request in a separate function
ss: create a function to print info about netlink sockets
ss: show destination address for netlink sockets
ss: Get netlink sockets info via sock-diag (v2)
Atzm Watanabe (1):
vxlan: Allow setting destination to unicast address.
Cong Wang (1):
add quickack option to ip route
Daniel Borkmann (1):
ip: ipv6: add tokenized interface identifier support
David L Stevens (1):
iproute2: support NTF_ROUTER flag in VXLAN fdb entries
David Stevens (1):
iproute2: generalize VXLAN forwarding tables
Eric Dumazet (4):
ss: add fastopen support
htb: report overhead attribute
get_rate: detect 32bit overflows
ss: add more TCP_INFO components
Jesper Dangaard Brouer (1):
linklayer interface between kernel and tc/userspace
John Fastabend (1):
iproute2: bridge: fix 'bridge link' setlink/getlink parsing
JunweiZhang (1):
ipbatch: fix use of 'ip netns exec'
Kamil Rytarowski (1):
iproute2 patch against GCC 4.8.0
Lutz Jaenicke (1):
macvlan: fix typo in macvlan_print_opt()
Martin Schwenke (1):
ip: Add label option to ip monitor
Nicolas Dichtel (8):
ip: add missing help about mode argument
ip/xfrm: all to set flag XFRM_SA_XFLAG_DONT_ENCAP_DSCP
ipnetconf: by default dump all entries
ss: allow to retrieve AF_PACKET info via netlink
man: describe --bpf option of ss
ipadress: fix display of IPv6 peer address
ip: allow to specify mode for sit tunnels
ipnetns: fix ip batch mode when using 'netns exec'
Patric McHardy (1):
ip: iplink_vlan: add 802.1ad support
Pavel Emelyanov (1):
ss: Show inet and unix sockets' shutdown state
Rami Rosen (1):
ss: replace bfp with bpf in usage().
Richard Godbee (3):
iproute2: iproute.c: fix usage() spacing problems
iproute2: spelling: noptmudisc -> nopmtudisc
iproute2: ip-route.8.in: minor fixes
Rony Efraim (1):
Add VF link state control
Sriram Narasimhan (1):
iptuntap: allow creation of multi-queue tun/tap device
Stefan Tomanek (1):
ip link: fix display of interface groups
Stephen Hemminger (21):
Update headers to 3.10
Add vxlan destination port option
vxlan: nag user to set port value
add BPF header files
vxlan: remove dstport option
man: get rid of useless reference to GNU style options
htb: fix indentation
update to 3.10-net-next headers
netns: follow return value conventions of the rest of the code
ip: add batch mode to man page
Make tc and ip batch mode consistent
v3.10.0
Update to 3.11-rc1 kernel headers
Remove -Werror
cleanup help message
Fix spelling errors
More minor spelling fixes
tc: allow qdisc without options
add ability to filter neighbour discovery by protocol
Update kernel headers to 3.11
v3.11.0
Thomas Egerer (1):
ip/xfrm: Fix potential SIGSEGV when printing extra flags
Thomas Richter (3):
iproute2 vxlan documentation update for bridge command
iproute2 vxlan documentation update for ip command
iproute vxlan add support for fdb replace command
esr@thyrsus.com (4):
First set of manpage markup fixes
tc-stab.8: Fix synopsis errors, an invalid escape, and incorrect English usge.
In tc-ematch.8, remove no-op .ti requests to prevent translation warnings
ip-rule.8: Fix presentational use of .SS.
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Eric Dumazet @ 2013-09-03 15:29 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Joakim Tjernlund, netdev
In-Reply-To: <1378219696.1545.9.camel@bwh-desktop.uk.level5networks.com>
On Tue, 2013-09-03 at 15:48 +0100, Ben Hutchings wrote:
> GRO should be beneficial for bridges if you have bursty TCP streams. It
> is especially beneficial if you also have TSO on the TX side.
>
> Really you're going to have to try it and run benchmarks with your own
> hardware.
Note that ucc_geth does not have GRO support (it calls
netif_receive_skb())
It doesnt have RX checksuming either, so having to validate
tcp checksums (before aggregating them in GRO stack) would hurt if
packets only have to be forwarded.
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-03 15:20 UTC (permalink / raw)
To: Fabio Estevam
Cc: David Miller, Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <CAOMZO5AHQr87ka2PrmMCQ0Dr46T=gB5_j1fz9BxhcjyWw9qSnw@mail.gmail.com>
> -----Original Message-----
> From: Fabio Estevam [mailto:festevam@gmail.com]
> Sent: Tuesday, September 03, 2013 10:15 AM
> To: Li Frank-B20596
> Cc: David Miller; Duan Fugang-B38611; netdev@vger.kernel.org;
> bhutchings@solarflare.com; stephen@networkplumber.org
> Subject: Re: [PATCH] net: fec: fix the error to get the previous BD entry
>
> On Tue, Sep 3, 2013 at 12:10 PM, Li Frank-B20596 <B20596@freescale.com>
> wrote:
> >
> >> > Acked
> >>
> >> This is not the correct way to ACK a patch, the correct format is:
> >>
> >> Acked-by: David S. Miller <davem@davemloft.net>
> >
> >
> > Thanks
> >
> > Acked-by: Frank Li <frank.li@freescale.net>
>
> I thought your email was freescale.com ;-)
Yes, I am wrong.
Sorry.
Acked-by: Frank Li <frank.li@freescale.com>
^ permalink raw reply
* Re: [PATCH] net: fec: fix the error to get the previous BD entry
From: Fabio Estevam @ 2013-09-03 15:14 UTC (permalink / raw)
To: Li Frank-B20596
Cc: David Miller, Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <1F990F8245A4214A8CC4BFFBD9F790F908B46E06@039-SN1MPN1-001.039d.mgd.msft.net>
On Tue, Sep 3, 2013 at 12:10 PM, Li Frank-B20596 <B20596@freescale.com> wrote:
>
>> > Acked
>>
>> This is not the correct way to ACK a patch, the correct format is:
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
>
>
> Thanks
>
> Acked-by: Frank Li <frank.li@freescale.net>
I thought your email was freescale.com ;-)
^ permalink raw reply
* RE: [PATCH] net: fec: fix the error to get the previous BD entry
From: Li Frank-B20596 @ 2013-09-03 15:10 UTC (permalink / raw)
To: David Miller
Cc: Duan Fugang-B38611, netdev@vger.kernel.org,
bhutchings@solarflare.com, stephen@networkplumber.org
In-Reply-To: <20130902.203506.1108904049878490946.davem@davemloft.net>
> > Acked
>
> This is not the correct way to ACK a patch, the correct format is:
>
> Acked-by: David S. Miller <davem@davemloft.net>
Thanks
Acked-by: Frank Li <frank.li@freescale.net>
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Ben Hutchings @ 2013-09-03 14:48 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF0F246C2A.B5DC5CA4-ONC1257BDB.004CA4E6-C1257BDB.004DB31E@transmode.se>
On Tue, 2013-09-03 at 16:08 +0200, Joakim Tjernlund wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
> >
> > On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > > I am considering impl. VLAN HW acceleration in Freescales ucc_geth
> driver
> > > to improve
> > > performance, primarily for bridged interfaces.
> > > I am hoping the community has some insights as to what performance
> gains
> > > one
> > > could expect?
> >
> > At the moment you need to do VLAN RX offload (or fake it in software) to
> > take advantage of GRO for VLAN-encapsulated packets. Other than that, I
> > don't think it makes a lot of difference in most situations.
> >
> > Ben.
>
> Thanks Ben
>
> I figured one would avoid some memmoves if the tag was extracted and as we
> got
> a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance
> but not so then.
Of course it will avoid some memmoves, I just don't think that makes
much of a difference any more. There used to be other more major
performance issues (like having to copy packets) but I believe they've
been fixed in the stack now.
> I am not familiar with GRO( and its friends) but I am guessing it won't
> help
> the bridge function or reduce stress from packet storms?
GRO should be beneficial for bridges if you have bursty TCP streams. It
is especially beneficial if you also have TSO on the TX side.
Really you're going to have to try it and run benchmarks with your own
hardware.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: use reciprocal_divide instead of reimplementing it
From: Daniel Borkmann @ 2013-09-03 14:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <1378216954.7360.25.camel@edumazet-glaptop>
On 09/03/2013 04:02 PM, Eric Dumazet wrote:
> On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
>> Replace these places with reciprocal_divide() inline function instead of
>> reimplementing it each time, thus it will become easier to read. We do not
>> need to explicitly include its header as it's pulled in from linux/net.h
>> anyway.
>
> Sure, (((u64) hash * qcount) >> 32) happens to be
> reciprocal_divide(hash, qcount) but the result depends on hash being
> well distributed in [0 .. ~0U] space.
>
> So 'reciprocal' and 'divide' do not accurately describe this exact
> operation.
>
> I suggest making the thing more descriptive.
>
> (And discussed on lkml btw)
Sure, we can do that. Then lets drop these two for now.
^ permalink raw reply
* Re: [guv v2 04/31] net: Replace __get_cpu_var uses
From: Christoph Lameter @ 2013-09-03 14:21 UTC (permalink / raw)
To: David Miller
Cc: dhowells, tj, akpm, netdev, linux-arch, srostedt, linux-kernel
In-Reply-To: <20130902.203355.117341085023152754.davem@davemloft.net>
On Mon, 2 Sep 2013, David Miller wrote:
> It really will cache pre-computed __thread pointer calculations across
> sched().
On x86 the compiler could use the segment prefix and then it may work.
^ permalink raw reply
* Re: [guv v2 04/31] net: Replace __get_cpu_var uses
From: Christoph Lameter @ 2013-09-03 14:20 UTC (permalink / raw)
To: David Howells
Cc: Tejun Heo, akpm, David S. Miller, netdev, linux-arch,
Steven Rostedt, linux-kernel
In-Reply-To: <7435.1378157706@warthog.procyon.org.uk>
On Mon, 2 Sep 2013, David Howells wrote:
> Would it be possible to use __thread annotations for per-CPU variables, I
> wonder?
We already have a __percpu annotation. Looked at __thread a couple of
years ago but found that support for the kernel segment register was not
available. If we had __thread then most of the operations could simply be
provided by the compiler.
^ permalink raw reply
* Re: [PATCH] net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
From: Vlad Yasevich @ 2013-09-03 14:16 UTC (permalink / raw)
To: Alexander Sverdlin
Cc: linux-sctp, davem, Glavinic-Pecotic, Matija (EXT-Other - DE/Ulm),
netdev
In-Reply-To: <52249981.8040006@nsn.com>
On 09/02/2013 09:58 AM, Alexander Sverdlin wrote:
> From: Alexander Sverdlin <alexander.sverdlin@nsn.com>
>
> net: sctp: Fix data chunk fragmentation for MTU values which are not multiple of 4
>
> Initially the problem was observed with ipsec, but later it became clear that
> SCTP data chunk fragmentation algorithm has problems with MTU values which are
> not multiple of 4. Test program was used which just transmits 2000 bytes long
> packets to other host. tcpdump was used to observe re-fragmentation in IP layer
> after SCTP already fragmented data chunks.
>
> With MTU 1500:
> 12:54:34.082904 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1500)
> 10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 2366088589] [SID: 0] [SSEQ 1] [PPID 0x0]
> 12:54:34.082933 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 596)
> 10.151.38.153.39303 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 2366088590] [SID: 0] [SSEQ 1] [PPID 0x0]
> 12:54:34.090576 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.39303: sctp (1) [SACK] [cum ack 2366088590] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> With MTU 1499:
> 13:02:49.955220 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 0, flags [+], proto SCTP (132), length 1492)
> 10.151.38.153.39084 > 10.151.24.91.54321: sctp[|sctp]
> 13:02:49.955249 IP (tos 0x2,ECT(0), ttl 64, id 48215, offset 1472, flags [none], proto SCTP (132), length 28)
> 10.151.38.153 > 10.151.24.91: ip-proto-132
> 13:02:49.955262 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
> 10.151.38.153.39084 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 404355346] [SID: 0] [SSEQ 1] [PPID 0x0]
> 13:02:49.956770 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.39084: sctp (1) [SACK] [cum ack 404355346] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> Here problem in data portion limit calculation leads to re-fragmentation in IP,
> which is sub-optimal. The problem is max_data initial value, which doesn't take
> into account the fact, that data chunk must be padded to 4-bytes boundary.
> It's enough to correct max_data, because all later adjustments are correctly
> aligned to 4-bytes boundary.
>
> After the fix is applied, everything is fragmented correctly for uneven MTUs:
> 15:16:27.083881 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 1496)
> 10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (B) [TSN: 3077098183] [SID: 0] [SSEQ 1] [PPID 0x0]
> 15:16:27.083907 IP (tos 0x2,ECT(0), ttl 64, id 0, offset 0, flags [DF], proto SCTP (132), length 600)
> 10.151.38.153.53417 > 10.151.24.91.54321: sctp (1) [DATA] (E) [TSN: 3077098184] [SID: 0] [SSEQ 1] [PPID 0x0]
> 15:16:27.085640 IP (tos 0x2,ECT(0), ttl 63, id 0, offset 0, flags [DF], proto SCTP (132), length 48)
> 10.151.24.91.54321 > 10.151.38.153.53417: sctp (1) [SACK] [cum ack 3077098184] [a_rwnd 79920] [#gap acks 0] [#dup tsns 0]
>
> The bug was there for years already, but
> - is a performance issue, the packets are still transmitted
> - doesn't show up with default MTU 1500, but possibly with ipsec (MTU 1438)
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
>
> --- linux-3.10.orig/net/sctp/chunk.c
> +++ linux-3.10/net/sctp/chunk.c
> @@ -200,9 +200,9 @@ struct sctp_datamsg *sctp_datamsg_from_u
> /* This is the biggest possible DATA chunk that can fit into
> * the packet
> */
> - max_data = asoc->pathmtu -
> + max_data = (asoc->pathmtu -
> sctp_sk(asoc->base.sk)->pf->af->net_header_len -
> - sizeof(struct sctphdr) - sizeof(struct sctp_data_chunk);
> + sizeof(struct sctphdr) - sizeof(struct sctp_data_chunk)) & ~3;
>
> max = asoc->frag_point;
> /* If the the peer requested that we authenticate DATA chunks
>
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Joakim Tjernlund @ 2013-09-03 14:08 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1378216216.1545.1.camel@bwh-desktop.uk.level5networks.com>
Ben Hutchings <bhutchings@solarflare.com> wrote on 2013/09/03 15:50:16:
>
> On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> > I am considering impl. VLAN HW acceleration in Freescales ucc_geth
driver
> > to improve
> > performance, primarily for bridged interfaces.
> > I am hoping the community has some insights as to what performance
gains
> > one
> > could expect?
>
> At the moment you need to do VLAN RX offload (or fake it in software) to
> take advantage of GRO for VLAN-encapsulated packets. Other than that, I
> don't think it makes a lot of difference in most situations.
>
> Ben.
Thanks Ben
I figured one would avoid some memmoves if the tag was extracted and as we
got
a fairly slow CPU (some 300 MHZ MPC 8321) one should gain some performance
but not so then.
I am not familiar with GRO( and its friends) but I am guessing it won't
help
the bridge function or reduce stress from packet storms?
Jocke
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: use reciprocal_divide instead of reimplementing it
From: Eric Dumazet @ 2013-09-03 14:02 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev, netfilter-devel
In-Reply-To: <1378204010-27050-3-git-send-email-dborkman@redhat.com>
On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
> Replace these places with reciprocal_divide() inline function instead of
> reimplementing it each time, thus it will become easier to read. We do not
> need to explicitly include its header as it's pulled in from linux/net.h
> anyway.
Sure, (((u64) hash * qcount) >> 32) happens to be
reciprocal_divide(hash, qcount) but the result depends on hash being
well distributed in [0 .. ~0U] space.
So 'reciprocal' and 'divide' do not accurately describe this exact
operation.
I suggest making the thing more descriptive.
(And discussed on lkml btw)
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: introduce generic net_random_N helper
From: Eric Dumazet @ 2013-09-03 13:59 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: davem, netdev
In-Reply-To: <1378204010-27050-2-git-send-email-dborkman@redhat.com>
On Tue, 2013-09-03 at 12:26 +0200, Daniel Borkmann wrote:
> We have implemented the same function over and over, so introduce a
> generic helper net_random_N() that unifies these implementations.
> It internally used net_random() which eventually resolves to
> prandom_u32(). Explicit include of reciprocal_div.h is not necessary.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> ---
It was private, so the name was whatever we chose at that time.
If we want to make it generic, why still doing a net_something() ?
Really this patch should be discussed on lkml and netdev and we should
use a generic name.
^ permalink raw reply
* Re: VLAN HW accel, performance advantage?
From: Ben Hutchings @ 2013-09-03 13:50 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF00E35E7C.7482EC01-ONC1257BDB.00314AD0-C1257BDB.0031F6D0@transmode.se>
On Tue, 2013-09-03 at 11:05 +0200, Joakim Tjernlund wrote:
> I am considering impl. VLAN HW acceleration in Freescales ucc_geth driver
> to improve
> performance, primarily for bridged interfaces.
> I am hoping the community has some insights as to what performance gains
> one
> could expect?
At the moment you need to do VLAN RX offload (or fake it in software) to
take advantage of GRO for VLAN-encapsulated packets. Other than that, I
don't think it makes a lot of difference in most situations.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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