* Re: [PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations
From: Marcel Holtmann @ 2017-05-22 8:28 UTC (permalink / raw)
To: SF Markus Elfring
Cc: linuxdev, linux-wpan, Network Development, Alexander Aring,
Harry Morris, Stefan Schmidt, LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
Hi Markus,
> Two update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
> Delete an error message for a failed memory allocation in ca8210_probe()
> Delete an error message for a failed memory allocation in ca8210_skb_rx()
>
> drivers/net/ieee802154/ca8210.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
both patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions
From: Marcel Holtmann @ 2017-05-22 8:25 UTC (permalink / raw)
To: SF Markus Elfring
Cc: open list:BLUETOOTH DRIVERS, Network Development, David S. Miller,
Gustavo F. Padovan, Johan Hedberg, LKML,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <0afbfdb7-48f1-4d15-d5bd-8ea40b1eb52a-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Hallo Markus,
> Omit two extra messages for memory allocation failures in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
> ---
> net/bluetooth/ecdh_helper.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH] flowcache: Delete an error message for a failed memory allocation in flow_cache_cpu_prepare()
From: SF Markus Elfring @ 2017-05-22 7:33 UTC (permalink / raw)
To: netdev, David S. Miller, Herbert Xu, Steffen Klassert
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 09:19:51 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/core/flow.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/flow.c b/net/core/flow.c
index f7f5d1932a27..08c851236b97 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -412,7 +412,6 @@ static int flow_cache_cpu_prepare(struct flow_cache *fc, int cpu)
- if (!fcp->hash_table) {
- pr_err("NET: failed to allocate flow cache sz %u\n", sz);
+ if (!fcp->hash_table)
return -ENOMEM;
- }
+
fcp->hash_rnd_recalc = 1;
fcp->hash_count = 0;
tasklet_init(&fcp->flush_tasklet, flow_cache_flush_tasklet, 0);
--
2.13.0
^ permalink raw reply related
* [PATCH net-next] net/wan/fsl_ucc_hdlc: fix muram allocation error
From: Holger Brunck @ 2017-05-22 7:31 UTC (permalink / raw)
To: netdev; +Cc: Holger Brunck, Zhao Qiang
sizeof(priv->ucc_pram) is 4 as it is the size of a pointer, but we want
to reserve space for the struct ucc_hdlc_param.
Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
Cc: Zhao Qiang <qiang.zhao@nxp.com>
---
drivers/net/wan/fsl_ucc_hdlc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index e9b2d687f150..33df76405b86 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -189,7 +189,7 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
}
/* Alloc parameter ram for ucc hdlc */
- priv->ucc_pram_offset = qe_muram_alloc(sizeof(priv->ucc_pram),
+ priv->ucc_pram_offset = qe_muram_alloc(sizeof(struct ucc_hdlc_param),
ALIGNMENT_OF_UCC_HDLC_PRAM);
if (priv->ucc_pram_offset < 0) {
--
2.12.0.rc1
^ permalink raw reply related
* Re: [PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()
From: Oliver Neukum @ 2017-05-22 7:08 UTC (permalink / raw)
To: SF Markus Elfring, linux-usb, netdev; +Cc: kernel-janitors, LKML
In-Reply-To: <3b831fce-93ed-c017-2549-967a39c2d1da@users.sourceforge.net>
Am Montag, den 22.05.2017, 07:09 +0200 schrieb SF Markus Elfring:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 22 May 2017 06:33:48 +0200
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* Re: [PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()
From: Oliver Neukum @ 2017-05-22 7:08 UTC (permalink / raw)
To: SF Markus Elfring, linux-usb, netdev; +Cc: kernel-janitors, LKML
In-Reply-To: <d5ae61d4-8339-29e4-e91c-90ba644d69aa@users.sourceforge.net>
Am Montag, den 22.05.2017, 07:10 +0200 schrieb SF Markus Elfring:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 22 May 2017 06:42:33 +0200
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Oliver Neukum <oneukum@suse.com>
^ permalink raw reply
* [PATCH] Bluetooth: Delete error messages for failed memory allocations in two functions
From: SF Markus Elfring @ 2017-05-22 6:54 UTC (permalink / raw)
To: linux-bluetooth, netdev, David S. Miller, Gustavo Padovan,
Johan Hedberg, Marcel Holtmann
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:42:28 +0200
Omit two extra messages for memory allocation failures in these functions.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
net/bluetooth/ecdh_helper.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
index 24d4e60f8c48..c7b1a9aee579 100644
--- a/net/bluetooth/ecdh_helper.c
+++ b/net/bluetooth/ecdh_helper.c
@@ -92,8 +92,6 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
+
crypto_ecdh_encode_key(buf, buf_len, &p);
/* Set A private Key */
@@ -173,8 +171,5 @@ bool generate_ecdh_keys(u8 public_key[64], u8 private_key[32])
- if (!buf) {
- pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
- buf_len);
+ if (!buf)
goto free_req;
- }
do {
if (tries++ >= max_tries)
--
2.13.0
^ permalink raw reply related
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Jesper Dangaard Brouer @ 2017-05-22 6:39 UTC (permalink / raw)
To: Tom Herbert
Cc: Daniel Borkmann, Alexei Starovoitov,
Linux Kernel Network Developers, brouer
In-Reply-To: <CALx6S34-4kQLQLkU9QRjyfZ808f_hXV4N+bh+XG8iu1BtQOUSA@mail.gmail.com>
On Sun, 21 May 2017 15:10:29 -0700
Tom Herbert <tom@herbertland.com> wrote:
> On Sun, May 21, 2017 at 9:04 AM, Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
> > On Sat, 20 May 2017 09:16:09 -0700
> > Tom Herbert <tom@herbertland.com> wrote:
> >
> >> > +/* XDP rxhash have an associated type, which is related to the RSS
> >> > + * (Receive Side Scaling) standard, but NIC HW have different mapping
> >> > + * and support. Thus, create mapping that is interesting for XDP. XDP
> >> > + * would primarly want insight into L3 and L4 protocol info.
> >> > + *
> >> > + * TODO: Likely need to get extended with "L3_IPV6_EX" due RSS standard
> >> > + *
> >> > + * The HASH_TYPE will be returned from bpf helper as the top 32-bit of
> >> > + * the 64-bit rxhash (internally type stored in xdp_buff->flags).
> >> > + */
> >> > +#define XDP_HASH(x) ((x) & ((1ULL << 32)-1))
> >> > +#define XDP_HASH_TYPE(x) ((x) >> 32)
> >> > +
> >> > +#define XDP_HASH_TYPE_L3_SHIFT 0
> >> > +#define XDP_HASH_TYPE_L3_BITS 3
> >> > +#define XDP_HASH_TYPE_L3_MASK ((1ULL << XDP_HASH_TYPE_L3_BITS)-1)
> >> > +#define XDP_HASH_TYPE_L3(x) ((x) & XDP_HASH_TYPE_L3_MASK)
> >> > +enum {
> >> > + XDP_HASH_TYPE_L3_IPV4 = 1,
> >> > + XDP_HASH_TYPE_L3_IPV6,
> >> > +};
> >> > +
> >> > +#define XDP_HASH_TYPE_L4_SHIFT XDP_HASH_TYPE_L3_BITS
> >> > +#define XDP_HASH_TYPE_L4_BITS 5
> >> > +#define XDP_HASH_TYPE_L4_MASK \
> >> > + (((1ULL << XDP_HASH_TYPE_L4_BITS)-1) << XDP_HASH_TYPE_L4_SHIFT)
> >> > +#define XDP_HASH_TYPE_L4(x) ((x) & XDP_HASH_TYPE_L4_MASK)
> >> > +enum {
> >> > + _XDP_HASH_TYPE_L4_TCP = 1,
> >> > + _XDP_HASH_TYPE_L4_UDP,
> >> > +};
> >> > +#define XDP_HASH_TYPE_L4_TCP (_XDP_HASH_TYPE_L4_TCP << XDP_HASH_TYPE_L4_SHIFT)
> >> > +#define XDP_HASH_TYPE_L4_UDP (_XDP_HASH_TYPE_L4_UDP << XDP_HASH_TYPE_L4_SHIFT)
> >> > +
> >> Hi Jesper,
> >>
> >> Why do we need these indicators for protocol specific hash? It seems
> >> like L4 and L3 is useful differentiation and protocol agnostic (I'm
> >> still holding out hope that SCTP will be deployed some day ;-) )
> >
> > I'm not sure I understood the question fully, but let me try to answer
> > anyway. To me it seems obvious that you would want to know the
> > protocol/L4 type, as this helps avoid hash collisions between UDP and
> > TCP flows. I can easily imagine someone constructing an UDP packet
> > that could hash collide with a given TCP flow.
> >
> > And yes, i40 support matching SCTP, and we will create a
> > XDP_HASH_TYPE_L4_SCTP when adding XDP rxhash support for that driver.
> >
> But where would this information be used? We don't save it in skbuff,
> don't use it in RPS, RFS. RSS doesn't use it for packet steering so
> the hash collision problem already exists at the device level. If
> there is a collision problem between two protocols then maybe hash
> should be over 5-tuple instead...
One use-case (I heard at a customer) was that they had (web-)servers
that didn't serve any UDP traffic, thus they simply block/drop all
incoming UDP on the service NIC (as an ACL in the switch). (The servers
own DNS lookups and NTP goes through the management NIC to internal
DNS/NTP servers).
Another use-case: Inside an XDP/bpf program is can be used for
splitting protocol processing, into different tail calls, before even
touching packet-data. I can imagine the bpf TCP handling code is
larger, thus an optimization is to have a separate tail call for the
UDP protocol handling. One could also transfer/queue all TCP traffic
to other CPU(s) like RPS, just without touching packet memory.
This info is saved in the skb, but due to space constrains, it is
reduced to a single bit, namely skb->l4_hash, iif some
RSS-proto/XDP_HASH_TYPE_L4_* bit was set. And the network stack do use
and react on this.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH 4750/4750] net: ipv4: tcp: fixed comment coding style issue
From: Rohit Chavan @ 2017-05-22 6:29 UTC (permalink / raw)
To: davem; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
Rohit Chavan
Fixed a coding style issue
Signed-off-by: Rohit Chavan <roheetchavan@gmail.com>
---
net/ipv4/tcp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 1e4c76d..87b0296 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2183,7 +2183,7 @@ void tcp_close(struct sock *sk, long timeout)
/* Now socket is owned by kernel and we acquire BH lock
- to finish close. No need to check for user refs.
+ * to finish close. No need to check for user refs.
*/
local_bh_disable();
bh_lock_sock(sk);
@@ -2471,7 +2471,8 @@ static int do_tcp_setsockopt(struct sock *sk, int level,
case TCP_MAXSEG:
/* Values greater than interface MTU won't take effect. However
* at the point when this call is done we typically don't yet
- * know which interface is going to be used */
+ * know which interface is going to be used
+ */
if (val && (val < TCP_MIN_MSS || val > MAX_TCP_WINDOW)) {
err = -EINVAL;
break;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_skb_rx()
From: SF Markus Elfring @ 2017-05-22 6:14 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:03:17 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ieee802154/ca8210.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25ed11bb5ed3..f6df75e80a60 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -1808,10 +1808,9 @@ static int ca8210_skb_rx(
/* Allocate mtu size buffer for every rx packet */
skb = dev_alloc_skb(IEEE802154_MTU + sizeof(hdr));
- if (!skb) {
- dev_crit(&priv->spi->dev, "dev_alloc_skb failed\n");
+ if (!skb)
return -ENOMEM;
- }
+
skb_reserve(skb, sizeof(hdr));
msdulen = data_ind[22]; /* msdu_length */
--
2.13.0
^ permalink raw reply related
* [PATCH 1/2] ieee802154: ca8210: Delete an error message for a failed memory allocation in ca8210_probe()
From: SF Markus Elfring @ 2017-05-22 6:13 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
In-Reply-To: <55fddbc7-28c4-8866-67d3-ff1ff1a4eeb7@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 07:32:46 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/ieee802154/ca8210.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ieee802154/ca8210.c b/drivers/net/ieee802154/ca8210.c
index 25fd3b04b3c0..25ed11bb5ed3 100644
--- a/drivers/net/ieee802154/ca8210.c
+++ b/drivers/net/ieee802154/ca8210.c
@@ -3143,10 +3143,6 @@ static int ca8210_probe(struct spi_device *spi_device)
pdata = kmalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
- dev_crit(
- &spi_device->dev,
- "Could not allocate platform data\n"
- );
ret = -ENOMEM;
goto error;
}
--
2.13.0
^ permalink raw reply related
* [PATCH 0/2] ieee802154: ca8210: Adjustments for two function implementations
From: SF Markus Elfring @ 2017-05-22 6:12 UTC (permalink / raw)
To: linuxdev, linux-wpan, netdev, Alexander Aring, Harry Morris,
Stefan Schmidt
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 08:08:04 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation in ca8210_probe()
Delete an error message for a failed memory allocation in ca8210_skb_rx()
drivers/net/ieee802154/ca8210.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
--
2.13.0
^ permalink raw reply
* [PATCH 2/2] usbnet: Improve a size determination in usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:10 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Oliver Neukum
Cc: LKML, kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <a81c2551-ce6c-967d-1120-4307f95b1e65-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
From: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
Date: Mon, 22 May 2017 06:42:33 +0200
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
Signed-off-by: Markus Elfring <elfring-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org>
---
drivers/net/usb/usbnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 802ba68d37d1..b73c2a40501c 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2129,6 +2129,6 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
}
- req = kmalloc(sizeof(struct usb_ctrlrequest), GFP_ATOMIC);
+ req = kmalloc(sizeof(*req), GFP_ATOMIC);
if (!req)
goto fail_free_buf;
--
2.13.0
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] usbnet: Delete an error message for a failed memory allocation in usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:09 UTC (permalink / raw)
To: linux-usb, netdev, Oliver Neukum; +Cc: LKML, kernel-janitors
In-Reply-To: <a81c2551-ce6c-967d-1120-4307f95b1e65@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 06:33:48 +0200
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/usb/usbnet.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 79048e72c1bd..802ba68d37d1 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -2124,10 +2124,7 @@ int usbnet_write_cmd_async(struct usbnet *dev, u8 cmd, u8 reqtype,
if (data) {
buf = kmemdup(data, size, GFP_ATOMIC);
- if (!buf) {
- netdev_err(dev->net, "Error allocating buffer"
- " in %s!\n", __func__);
+ if (!buf)
goto fail_free;
- }
}
--
2.13.0
^ permalink raw reply related
* [PATCH 0/2] usbnet: Adjustments for usbnet_write_cmd_async()
From: SF Markus Elfring @ 2017-05-22 5:07 UTC (permalink / raw)
To: linux-usb, netdev, Oliver Neukum; +Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Mon, 22 May 2017 07:04:03 +0200
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
Improve a size determination
drivers/net/usb/usbnet.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--
2.13.0
^ permalink raw reply
* Fw: [Bug 195835] New: regression: tcp_fastretrans_alert
From: Stephen Hemminger @ 2017-05-22 4:14 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Sun, 21 May 2017 08:53:17 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 195835] New: regression: tcp_fastretrans_alert
https://bugzilla.kernel.org/show_bug.cgi?id=195835
Bug ID: 195835
Summary: regression: tcp_fastretrans_alert
Product: Networking
Version: 2.5
Kernel Version: 4.11.2
Hardware: x86-64
OS: Linux
Tree: Mainline
Status: NEW
Severity: high
Priority: P1
Component: IPV4
Assignee: stephen@networkplumber.org
Reporter: nanericwang@gmail.com
Regression: No
The issue can be reproduced in 4.11 running netfilter and Transmission
BitTorrent. However 4.10.x has no such issue.
[May21 16:38] ------------[ cut here ]------------
[ +0.000044] WARNING: CPU: 3 PID: 0 at net/ipv4/tcp_input.c:2819
tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] Modules linked in: xt_TPROXY iptable_mangle xt_owner xt_REDIRECT
nf_nat_redirect xt_set af_packet iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_set_hash_net i
[ +0.000100] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.11.2 #2
[ +0.000004] Hardware name: BIOSTAR Group A68N-5000/A68N-5000, BIOS 4.6.5
04/22/2014
[ +0.000002] Call Trace:
[ +0.000007] <IRQ>
[ +0.000010] ? dump_stack+0x46/0x5e
[ +0.000009] ? __warn+0xb4/0xd0
[ +0.000006] ? tcp_fastretrans_alert+0x7ff/0xa10
[ +0.000006] ? tcp_ack+0xe95/0x1448
[ +0.000009] ? __ip_flush_pending_frames.isra.51+0x70/0x70
[ +0.000007] ? tcp_rcv_established+0x1ae/0x6b0
[ +0.000007] ? tcp_v4_do_rcv+0x12b/0x1e8
[ +0.000006] ? tcp_v4_rcv+0x7c4/0x880
[ +0.000011] ? nf_nat_ipv4_fn+0x53/0x150 [nf_nat_ipv4]
[ +0.000007] ? ip_local_deliver_finish+0x49/0x110
[ +0.000006] ? ip_local_deliver+0x66/0xd8
[ +0.000006] ? inet_del_offload+0x30/0x30
[ +0.000008] ? ip_sabotage_in+0x26/0x30 [br_netfilter]
[ +0.000009] ? nf_hook_slow+0x21/0xa0
[ +0.000005] ? ip_rcv+0x2e8/0x370
[ +0.000006] ? ip_local_deliver_finish+0x110/0x110
[ +0.000008] ? __netif_receive_skb_core+0x363/0x700
[ +0.000007] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000014] ? br_pass_frame_up+0x60/0xd8 [bridge]
[ +0.000012] ? br_handle_frame_finish+0x132/0x330 [bridge]
[ +0.000015] ? nf_ct_get_tuple+0x56/0x90 [nf_conntrack]
[ +0.000011] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? br_nf_hook_thresh+0xa7/0xb8 [br_netfilter]
[ +0.000009] ? ipt_do_table+0x2b5/0x3e0 [ip_tables]
[ +0.000007] ? br_nf_pre_routing_finish+0x173/0x2f8 [br_netfilter]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000007] ? nf_nat_ipv4_in+0x23/0x70 [nf_nat_ipv4]
[ +0.000007] ? br_nf_pre_routing+0x2c4/0x420 [br_netfilter]
[ +0.000007] ? br_nf_forward_arp+0x250/0x250 [br_netfilter]
[ +0.000007] ? nf_hook_slow+0x21/0xa0
[ +0.000010] ? br_handle_frame+0x1ae/0x2c8 [bridge]
[ +0.000010] ? br_pass_frame_up+0xd8/0xd8 [bridge]
[ +0.000010] ? br_handle_local_finish+0x38/0x38 [bridge]
[ +0.000006] ? __netif_receive_skb_core+0x1d7/0x700
[ +0.000006] ? netif_receive_skb_internal+0x2a/0x98
[ +0.000006] ? napi_gro_receive+0x6a/0xb0
[ +0.000012] ? rtl8169_poll+0x2c9/0x690 [r8169]
[ +0.000007] ? net_rx_action+0x1c6/0x2b8
[ +0.000007] ? __do_softirq+0xd8/0x200
[ +0.000005] ? irq_exit+0xa3/0xa8
[ +0.000007] ? do_IRQ+0x45/0xc0
[ +0.000009] ? common_interrupt+0x7f/0x7f
[ +0.000003] </IRQ>
[ +0.000013] ? acpi_idle_do_entry+0x2b/0xed0 [processor]
[ +0.000007] ? acpi_idle_enter+0xe1/0x288 [processor]
[ +0.000009] ? cpuidle_enter_state+0x128/0x1f0
[ +0.000008] ? do_idle+0x17a/0x1d8
[ +0.000006] ? cpu_startup_entry+0x68/0x70
[ +0.000009] ? start_secondary+0x138/0x158
[ +0.000005] ? start_cpu+0x14/0x14
[ +0.000008] ---[ end trace ab2d840ff39c9793 ]---
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: John Fastabend @ 2017-05-22 4:12 UTC (permalink / raw)
To: Alexei Starovoitov, Jesper Dangaard Brouer; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20170522032129.kjxf465zbj6dfoaw@ast-mbp>
On 05/21/2017 08:21 PM, Alexei Starovoitov wrote:
> On Sun, May 21, 2017 at 05:55:50PM +0200, Jesper Dangaard Brouer wrote:
>>> And it looks useful to me, but
>>
>>> 1. i'm worried that we'd be relying on something that mellanox didn't
>>> implement in their drivers before. Was it tested and guarnteed to
>>> exist in the future revisions of firmware? Is it cx4 or cx4-lx or cx5
>>> feature?
>>
>> It is not a hidden mlx5 or specific feature. Due to the Microsoft RSS
>> standard/requirements[2] most NICs actually implement this.
>>
>> [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types
>
> ...
>
>>> 2. but the main concern that it is mellanox only feature. At least I cannot
>>> see anything like this in broadcom and intel nics
>>
>> All the drivers I looked at have support for an RSS hash type.
>> Including Broadcom[3] and Intel. Just grep after NETIF_F_RXHASH, and
>> follow data-structs. The Intel i40 NIC have the most elaborate rss type
>> system (it can e.g. tell if this was SCTP).
>>
>> [3] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h#L4198
>
> yes and bnxt too.
> msft spec requires RSS to be configured in these different ways, but
> it doesn't mean that HW descriptor will have 'is_v4' and 'is_v6' bits set.
> imo this is mlx specific behavior.
> If you want to piggy back on msft spec and make linux rss to be configurable
> the same way, I guess that's fine, but imo it's orthogonal to xdp.
>
>>> How about exposing 'struct mlx5_cqe64 *' to XDP programs as-is?
>>> We can make sure that XDP program does read only access into it and
>>> it will see cqe->rss_hash_result, cqe->rss_hash_type and everything else
>>> in there, but this will not be uapi and it will be pretty obvious
>>> to program authors that their programs are vendor specific.
>>
>> This sounds EXTREMELY dangerous to me... IHMO this will lead to vendor
>> lock-in. As BPF program authors will become dependent on vendor
>> specific features, and their program are no longer portable to run on
>> other NICs.
>>
>> How are you going to avoid vendor lock-in with this model?
>
> It looked to me that that was the intent of your patch set, hence
> counter proposal to make it much simpler.
> I'm not going to use vendor specific features. The proposal
> to expose hw rx descriptor as-is is for people who desperately want
> that info without burdening core xdp with it.
>
>>> 'not uapi' here means that mellanox is free to change their HW descriptor
>>> and its contents as they wish.
>>
>> Hmmm... IMHO directly exposing the HW descriptor to userspace, will
>> limit vendors ability to change its contents.
>
> kprobes can already look at hw rx descriptor.
> if somebody really wants to look into it, they have a way to do it already:
> - add kprobe to mlx5e_handle_rx_cqe(), look into cqe, store the outcome on a side
> - use that info in the xdp program
> All I proposed is to make it first class citizen and avoid kprobe.
>
Another solution is to have hardware prepend meta-data to the front of the
packet and have the XDP program read it out. Of course the hardware and
XDP program need to be in sync at this point, but it works today assuming
a mechanism to program hardware exists.
The nice part of the above is you push all the complexity of feature negotiation
and hardware initialization out of XDP core completely.
This would be my preferred solution, except I'm not sure if some hardware
would have issue with this.
.John
^ permalink raw reply
* Re: [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: Willem de Bruijn @ 2017-05-22 3:50 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Miroslav Lichvar, Willem de Bruijn
In-Reply-To: <20170521.233552.1330381397679616478.davem@davemloft.net>
On Sun, May 21, 2017 at 11:35 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Date: Sun, 21 May 2017 23:31:47 -0400
>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
>> is defined in asm-generic/socket.h. Also define it in the architecture
>> specific versions.
>>
>> Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> CC: Miroslav Lichvar <mlichvar@redhat.com>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> I pushed a fix for this about 15 minutes ago :-).
Thanks, David!
Then ignore this one. Apologies for not spotting this sooner.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2017-05-22 3:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170521.231410.1999783448679718181.davem@davemloft.net>
Hi Dave,
On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 22 May 2017 11:16:05 +1000
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > net/socket.c: In function 'put_ts_pktinfo':
> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> > put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> > ^
> > Caused by commit
> >
> > aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
> >
> > This probably broke every architecture that has its own
> > arch/<arch>/include/uapi/asm/socket.h that does not include
> > include/uapi/asm-generic/socket.h :-(
> >
> > I have used the net-next tree from next-20170519 for today.
>
> I've just pushed the following, thanks for the report:
Looks good except:
> diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
> index 5147018..784b871 100644
> --- a/arch/parisc/include/uapi/asm/socket.h
> +++ b/arch/parisc/include/uapi/asm/socket.h
> @@ -97,4 +97,6 @@
>
> #define SO_COOKIE 0x4032
>
> +#define SCM_TIMESTAMPING_PKTINFO 58
Does this need to be 0x4033 (or something)?
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Willem de Bruijn @ 2017-05-22 3:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux-Next Mailing List,
Linux Kernel Mailing List, Miroslav Lichvar, Willem de Bruijn
In-Reply-To: <20170522111605.14f93676@canb.auug.org.au>
On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
>
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>
> This probably broke every architecture that has its own
> arch/<arch>/include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
Indeed. I added the architecture specific versions in patch
http://patchwork.ozlabs.org/patch/765238/
That fixes the powerpc build for me. The new option is now
defined in every file that also defines the last added such
option SCM_TIMESTAMPING_OPT_STATS. Apologies for
missing this earlier.
^ permalink raw reply
* Re: [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: David Miller @ 2017-05-22 3:35 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: netdev, mlichvar, willemb
In-Reply-To: <20170522033147.17264-1-willemdebruijn.kernel@gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Sun, 21 May 2017 23:31:47 -0400
> From: Willem de Bruijn <willemb@google.com>
>
> The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
> is defined in asm-generic/socket.h. Also define it in the architecture
> specific versions.
>
> Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Miroslav Lichvar <mlichvar@redhat.com>
> Signed-off-by: Willem de Bruijn <willemb@google.com>
I pushed a fix for this about 15 minutes ago :-)
^ permalink raw reply
* [PATCH net-next] net: define PKTINFO timestamping option in all archs
From: Willem de Bruijn @ 2017-05-22 3:31 UTC (permalink / raw)
To: netdev; +Cc: davem, mlichvar, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
The newly introduced timestamping option SCM_TIMESTAMPING_PKTINFO
is defined in asm-generic/socket.h. Also define it in the architecture
specific versions.
Fixes: aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Miroslav Lichvar <mlichvar@redhat.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 148d7a32754e..0926de63a62b 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 1ccf45657472..e491ff08b9a9 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b48042a..869372413333 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index ae6548d29a18..5d97890a8704 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 3418ec9c1c50..365ff51f033a 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92301a6..d013c0da0256 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 514701840bd9..b893ca14fade 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 0x4033
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0310fc..bc4ca72faf99 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf673fd..fb9769d7e74e 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19d9ec7..5d673302fd41 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 1eb6d2fe70d3..982c2533f912 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -109,4 +109,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _XTENSA_SOCKET_H */
--
2.13.0.303.g4ebf302169-goog
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH 0/4] Configuring traffic classes via new hardware offload mechanism in tc/mqprio
From: Or Gerlitz @ 2017-05-22 3:25 UTC (permalink / raw)
To: Alexander Duyck; +Cc: Amritha Nambiar, intel-wired-lan, Linux Netdev List
In-Reply-To: <CAKgT0Ue6tDOE8L4thktyje-erGkVMmtO7zyp0FRgmRPYOppjQA@mail.gmail.com>
On Mon, May 22, 2017 at 1:35 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Sat, May 20, 2017 at 2:15 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Sat, May 20, 2017 at 3:58 AM, Amritha Nambiar
>> <amritha.nambiar@intel.com> wrote:
>>> The following series introduces a new harware offload mode in tc/mqprio
>>
>> Wait, we have already a HW QoS model introduced by John F and Co
>> couple of years ago, right?
>
> I assume you are referring to the ETS portion of DCBX? If so then yes
> we have something there, but there is a fairly high level of
> complexity and dependencies in order to enable that. What we have in
> mind doesn't really fit with DCBX and the problem is the spec calls
> out that you really have to have support for DCBX in order to make use
> of ETS. What we are trying to do here is provide a lightweight way of
> doing this configuration similar to how mqprio was already providing a
> lightweight way of enabling multiple traffic classes.
UAPI wise, we are talking on DCB, not DCBX, right? the X-portion comes
into play if some user-space entity run LLDP traffic and calls into
the kernel to configure (say) ETS. If there are some issues to use the
existing user-space tool (lldpad tool/daemon) to do DCB without X, one
can/should fix them or introduce another/simpler tool that in a
lightweight manner only configures things w.o exchanging.
So to clarify, the essence of this series is introducing a 2nd way to
configure ETS and rate limit?
>> Please elaborate in few sentence if you are extending it/replacing it,
>> why we want to do that and what are the implications on existing
>> applications UAPI wise.
> This is meant to be an extension of the existing structure. It can be
> ignored by the driver and instead only have the basic hw offload
> supported. In such a case the command will still return success but
> any rate limits and queue configuration can be ignored. In the case of
> the current implementation the queue configuration was already being
> ignored so we opted to re-purpose the "hw" flag so that if you pass a
> value greater than 1 and the driver doesn't recognize the value it has
> the option to just ignore the extra bits it doesn't recognize and
> return 1 as it did before for the hw flag in mqprio.
So the user asked to configure something and the kernel returned
success but the config was not plugged to the hw? sounds to me like
possible (probable) source of troubles and complaints.
>> Below you just say in the new mode Qos is configured with knobs XYZ --
>> this is way not enough
> Can you clarify what you are asking for here? Amritha included an
> example in patch 1 of a command line that enabled 2 traffic classes
> with rate limits. Is there something more specific you are looking for?
you were referring to the questions I posted, so we can continue the
discussion from here.
^ permalink raw reply
* Re: [RFC net-next PATCH 4/5] net: new XDP feature for reading HW rxhash from drivers
From: Alexei Starovoitov @ 2017-05-22 3:21 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Daniel Borkmann, netdev
In-Reply-To: <20170521175550.762b2cf8@redhat.com>
On Sun, May 21, 2017 at 05:55:50PM +0200, Jesper Dangaard Brouer wrote:
> > And it looks useful to me, but
>
> > 1. i'm worried that we'd be relying on something that mellanox didn't
> > implement in their drivers before. Was it tested and guarnteed to
> > exist in the future revisions of firmware? Is it cx4 or cx4-lx or cx5
> > feature?
>
> It is not a hidden mlx5 or specific feature. Due to the Microsoft RSS
> standard/requirements[2] most NICs actually implement this.
>
> [2] https://docs.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types
...
> > 2. but the main concern that it is mellanox only feature. At least I cannot
> > see anything like this in broadcom and intel nics
>
> All the drivers I looked at have support for an RSS hash type.
> Including Broadcom[3] and Intel. Just grep after NETIF_F_RXHASH, and
> follow data-structs. The Intel i40 NIC have the most elaborate rss type
> system (it can e.g. tell if this was SCTP).
>
> [3] http://elixir.free-electrons.com/linux/latest/source/drivers/net/ethernet/broadcom/bnx2x/bnx2x_hsi.h#L4198
yes and bnxt too.
msft spec requires RSS to be configured in these different ways, but
it doesn't mean that HW descriptor will have 'is_v4' and 'is_v6' bits set.
imo this is mlx specific behavior.
If you want to piggy back on msft spec and make linux rss to be configurable
the same way, I guess that's fine, but imo it's orthogonal to xdp.
> > How about exposing 'struct mlx5_cqe64 *' to XDP programs as-is?
> > We can make sure that XDP program does read only access into it and
> > it will see cqe->rss_hash_result, cqe->rss_hash_type and everything else
> > in there, but this will not be uapi and it will be pretty obvious
> > to program authors that their programs are vendor specific.
>
> This sounds EXTREMELY dangerous to me... IHMO this will lead to vendor
> lock-in. As BPF program authors will become dependent on vendor
> specific features, and their program are no longer portable to run on
> other NICs.
>
> How are you going to avoid vendor lock-in with this model?
It looked to me that that was the intent of your patch set, hence
counter proposal to make it much simpler.
I'm not going to use vendor specific features. The proposal
to expose hw rx descriptor as-is is for people who desperately want
that info without burdening core xdp with it.
> > 'not uapi' here means that mellanox is free to change their HW descriptor
> > and its contents as they wish.
>
> Hmmm... IMHO directly exposing the HW descriptor to userspace, will
> limit vendors ability to change its contents.
kprobes can already look at hw rx descriptor.
if somebody really wants to look into it, they have a way to do it already:
- add kprobe to mlx5e_handle_rx_cqe(), look into cqe, store the outcome on a side
- use that info in the xdp program
All I proposed is to make it first class citizen and avoid kprobe.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: David Miller @ 2017-05-22 3:14 UTC (permalink / raw)
To: sfr; +Cc: netdev, linux-next, linux-kernel, mlichvar, willemb
In-Reply-To: <20170522111605.14f93676@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 22 May 2017 11:16:05 +1000
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use in this function)
> put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
> Caused by commit
>
> aad9c8c470f2 ("net: add new control message for incoming HW-timestamped packets")
>
> This probably broke every architecture that has its own
> arch/<arch>/include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
>
> I have used the net-next tree from next-20170519 for today.
I've just pushed the following, thanks for the report:
====================
net: Define SCM_TIMESTAMPING_PKTINFO on all architectures.
A definition was only provided for asm-generic/socket.h
using platforms, define it for the others as well
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/alpha/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 2 ++
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 2 ++
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 2 ++
arch/xtensa/include/uapi/asm/socket.h | 2 ++
11 files changed, 22 insertions(+)
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 148d7a3..0926de6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 1ccf456..e491ff0 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b4..8693724 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index ae6548d..5d97890 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 3418ec9..365ff51 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92..d013c0d 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index 5147018..784b871 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
#define SO_COOKIE 0x4032
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0..bc4ca72 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf..fb9769d 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19..5d67330 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
#define SO_COOKIE 0x003b
+#define SCM_TIMESTAMPING_PKTINFO 0x003c
+
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
#define SO_SECURITY_ENCRYPTION_TRANSPORT 0x5002
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 1eb6d2f..982c253 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -109,4 +109,6 @@
#define SO_COOKIE 57
+#define SCM_TIMESTAMPING_PKTINFO 58
+
#endif /* _XTENSA_SOCKET_H */
--
2.7.4
^ 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