* Re: bonded active-backup ethernet-wifi drops packets
From: Jay Vosburgh @ 2019-07-06 0:46 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: netdev
In-Reply-To: <8d40b6ed3bf8a7540cff26e3834f0296228d9922.camel@interlinx.bc.ca>
Brian J. Murrell <brian@interlinx.bc.ca> wrote:
>On Tue, 2019-06-18 at 14:57 -0400, Brian J. Murrell wrote:
>> Hi.
>>
>> I have an active-backup bonded connection on a 5.1.6 kernel where the
>> slaves are an Ethernet interface and a wifi interface. The goal is
>> to
>> have network transparent (i.e. same and IP address on both
>> interfaces)
>> interface which takes advantage of high-speed and low-latency when it
>> can be physically plugged into the wired network but have portability
>> when unplugged through WiFi.
>>
>> It all works, mostly. :-/
>>
>> I find that even when the primary interface, being the Ethernet
>> interface is plugged in and active, the bonded interface will drop
>> packets periodically.
>>
>> If I down the bonded interface and plumb the Ethernet interface
>> directly, not as a slave of the bonded interface, no such packet
>> dropping occurs.
>>
>> My measure of packet dropping, is by observing the output of "sudo
>> ping
>> -f <ip_address>. In less than a few minutes even, on the bonded
>> interface, even with the Ethernet interface as the active slave, I
>> will
>> have a long string of dots indicating pings that were never
>> replied. On the unbonded Ethernet interface, no dots, even when
>> measured over many days.
>>
>> My bonding config:
>>
>> $ cat /proc/net/bonding/bond0
>> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>>
>> Bonding Mode: fault-tolerance (active-backup)
>> Primary Slave: enp0s31f6 (primary_reselect always)
>> Currently Active Slave: enp0s31f6
>> MII Status: up
>> MII Polling Interval (ms): 100
>> Up Delay (ms): 0
>> Down Delay (ms): 0
>>
>> Slave Interface: enp0s31f6
>> MII Status: up
>> Speed: 1000 Mbps
>> Duplex: full
>> Link Failure Count: 0
>> Permanent HW addr: 0c:54:15:4a:b2:0d
>> Slave queue ID: 0
>>
>> Slave Interface: wlp2s0
>> MII Status: up
>> Speed: Unknown
>> Duplex: Unknown
>> Link Failure Count: 1
>> Permanent HW addr: 0c:54:15:4a:b2:0d
>> Slave queue ID: 0
>>
>> Current interface config/stats:
>>
>> $ ifconfig bond0
>> bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
>> inet 10.75.22.245 netmask 255.255.255.0 broadcast
>> 10.75.22.255
>> inet6 fe80::ee66:b8c9:d55:a28f prefixlen 64 scopeid
>> 0x20<link>
>> inet6 2001:123:ab:123:d36d:5e5d:acc8:e9bc prefixlen
>> 64 scopeid 0x0<global>
>> ether 0c:54:15:4a:b2:0d txqueuelen 1000 (Ethernet)
>> RX packets 1596206 bytes 165221404 (157.5 MiB)
>> RX errors 0 dropped 0 overruns 0 frame 0
>> TX packets 1590552 bytes 162689350 (155.1 MiB)
>> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
>>
>> Devices:
>> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection
>> (2) I219-LM (rev 31)
>> 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275
>> (rev 78)
>>
>> Happy to provide any other useful information.
>>
>> Any ideas why the dropping, only when using the bonded interface?
>
>Wondering if I have the wrong list with this question. Is there a list
>where this question would be more on-topic or focused?
Not that I'm aware of; netdev is where bonding development
discussions and such take place.
>Perhaps I didn't provide enough information? I am happy to provide
>whatever is needed. I just don't know what more is needed at this
>point.
I did set this up and test it, but haven't had time to analyze
in depth.
What I saw was that ping (IPv4) flood worked fine, bonded or
not, over a span of several hours. However, ping6 showed small numbers
of drops on a ping6 flood when bonded, on the order of 200 drops out of
48,000,000 requests sent. Zero losses when no bond in the stack. Both
tests to the same peer connected to the same switch. All of the above
with the bond using the Ethernet slave. I haven't tracked down where
those losses are occurring, so I don't know if it's on the transmit or
receive sides (or both).
I did this testing on a laptop with iwlwifi (Centrino 6205) and
an e1000e (82579LM) network device, using the a kernel built from
net-next as of earlier this week (it claimed to be 5.2.0-rc5+).
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* [PATCH v9 net-next 2/5] net: ethernet: ti: davinci_cpdma: add dma mapped submit
From: Ivan Khoronzhuk @ 2019-07-05 23:57 UTC (permalink / raw)
To: grygorii.strashko, hawk, davem
Cc: ast, linux-kernel, linux-omap, xdp-newbies, ilias.apalodimas,
netdev, daniel, jakub.kicinski, john.fastabend, Ivan Khoronzhuk
In-Reply-To: <20190705150502.6600-3-ivan.khoronzhuk@linaro.org>
In case if dma mapped packet needs to be sent, like with XDP
page pool, the "mapped" submit can be used. This patch adds dma
mapped submit based on regular one.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
v9..v8
- fix potential warnings on arm64 caused by typos in type casting
drivers/net/ethernet/ti/davinci_cpdma.c | 89 ++++++++++++++++++++++---
drivers/net/ethernet/ti/davinci_cpdma.h | 4 ++
2 files changed, 83 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 5cf1758d425b..4e693c3aab27 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -139,6 +139,7 @@ struct submit_info {
int directed;
void *token;
void *data;
+ int flags;
int len;
};
@@ -184,6 +185,8 @@ static struct cpdma_control_info controls[] = {
(directed << CPDMA_TO_PORT_SHIFT)); \
} while (0)
+#define CPDMA_DMA_EXT_MAP BIT(16)
+
static void cpdma_desc_pool_destroy(struct cpdma_ctlr *ctlr)
{
struct cpdma_desc_pool *pool = ctlr->pool;
@@ -1015,6 +1018,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
struct cpdma_chan *chan = si->chan;
struct cpdma_ctlr *ctlr = chan->ctlr;
int len = si->len;
+ int swlen = len;
struct cpdma_desc __iomem *desc;
dma_addr_t buffer;
u32 mode;
@@ -1036,16 +1040,22 @@ static int cpdma_chan_submit_si(struct submit_info *si)
chan->stats.runt_transmit_buff++;
}
- buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
- ret = dma_mapping_error(ctlr->dev, buffer);
- if (ret) {
- cpdma_desc_free(ctlr->pool, desc, 1);
- return -EINVAL;
- }
-
mode = CPDMA_DESC_OWNER | CPDMA_DESC_SOP | CPDMA_DESC_EOP;
cpdma_desc_to_port(chan, mode, si->directed);
+ if (si->flags & CPDMA_DMA_EXT_MAP) {
+ buffer = (dma_addr_t)si->data;
+ dma_sync_single_for_device(ctlr->dev, buffer, len, chan->dir);
+ swlen |= CPDMA_DMA_EXT_MAP;
+ } else {
+ buffer = dma_map_single(ctlr->dev, si->data, len, chan->dir);
+ ret = dma_mapping_error(ctlr->dev, buffer);
+ if (ret) {
+ cpdma_desc_free(ctlr->pool, desc, 1);
+ return -EINVAL;
+ }
+ }
+
/* Relaxed IO accessors can be used here as there is read barrier
* at the end of write sequence.
*/
@@ -1055,7 +1065,7 @@ static int cpdma_chan_submit_si(struct submit_info *si)
writel_relaxed(mode | len, &desc->hw_mode);
writel_relaxed((uintptr_t)si->token, &desc->sw_token);
writel_relaxed(buffer, &desc->sw_buffer);
- writel_relaxed(len, &desc->sw_len);
+ writel_relaxed(swlen, &desc->sw_len);
desc_read(desc, sw_len);
__cpdma_chan_submit(chan, desc);
@@ -1079,6 +1089,32 @@ int cpdma_chan_idle_submit(struct cpdma_chan *chan, void *token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->state == CPDMA_STATE_TEARDOWN) {
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si(&si);
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return ret;
+}
+
+int cpdma_chan_idle_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(&chan->lock, flags);
if (chan->state == CPDMA_STATE_TEARDOWN) {
@@ -1103,6 +1139,32 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
si.data = data;
si.len = len;
si.directed = directed;
+ si.flags = 0;
+
+ spin_lock_irqsave(&chan->lock, flags);
+ if (chan->state != CPDMA_STATE_ACTIVE) {
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return -EINVAL;
+ }
+
+ ret = cpdma_chan_submit_si(&si);
+ spin_unlock_irqrestore(&chan->lock, flags);
+ return ret;
+}
+
+int cpdma_chan_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed)
+{
+ struct submit_info si;
+ unsigned long flags;
+ int ret;
+
+ si.chan = chan;
+ si.token = token;
+ si.data = (void *)data;
+ si.len = len;
+ si.directed = directed;
+ si.flags = CPDMA_DMA_EXT_MAP;
spin_lock_irqsave(&chan->lock, flags);
if (chan->state != CPDMA_STATE_ACTIVE) {
@@ -1140,10 +1202,17 @@ static void __cpdma_chan_free(struct cpdma_chan *chan,
uintptr_t token;
token = desc_read(desc, sw_token);
- buff_dma = desc_read(desc, sw_buffer);
origlen = desc_read(desc, sw_len);
- dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
+ buff_dma = desc_read(desc, sw_buffer);
+ if (origlen & CPDMA_DMA_EXT_MAP) {
+ origlen &= ~CPDMA_DMA_EXT_MAP;
+ dma_sync_single_for_cpu(ctlr->dev, buff_dma, origlen,
+ chan->dir);
+ } else {
+ dma_unmap_single(ctlr->dev, buff_dma, origlen, chan->dir);
+ }
+
cpdma_desc_free(pool, desc, 1);
(*chan->handler)((void *)token, outlen, status);
}
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
index 9343c8c73c1b..0271a20c2e09 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -77,8 +77,12 @@ int cpdma_chan_stop(struct cpdma_chan *chan);
int cpdma_chan_get_stats(struct cpdma_chan *chan,
struct cpdma_chan_stats *stats);
+int cpdma_chan_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed);
int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
int len, int directed);
+int cpdma_chan_idle_submit_mapped(struct cpdma_chan *chan, void *token,
+ dma_addr_t data, int len, int directed);
int cpdma_chan_idle_submit(struct cpdma_chan *chan, void *token, void *data,
int len, int directed);
int cpdma_chan_process(struct cpdma_chan *chan, int quota);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next 00/12] mlx5 TLS TX HW offload support
From: David Miller @ 2019-07-05 23:29 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe, saeedm, jakub.kicinski, moshe
In-Reply-To: <1562340622-4423-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Fri, 5 Jul 2019 18:30:10 +0300
> This series from Eran and me, adds TLS TX HW offload support to
> the mlx5 driver.
Series applied, please deal with any further feedback you get from
Jakub et al.
Thanks.
^ permalink raw reply
* Re: [PATCH 06/15 net-next,v2] net: sched: add tcf_setup_block_offload()
From: Jakub Kicinski @ 2019-07-05 23:27 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-7-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:34 +0200, Pablo Neira Ayuso wrote:
> Most drivers do the same thing to set up the block, add a helper
> function to do this.
>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
> index 534a545ea51e..003f24a1323f 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -922,6 +922,26 @@ static int tcf_block_setup(struct tcf_block *block, struct tc_block_offload *bo)
> return err;
> }
>
> +int tcf_setup_block_offload(struct tc_block_offload *f, tc_setup_cb_t *cb,
> + void *cb_ident, void *cb_priv, bool ingress_only)
> +{
> + if (ingress_only &&
> + f->binder_type != TCF_BLOCK_BINDER_TYPE_CLSACT_INGRESS)
> + return -EOPNOTSUPP;
> +
> + switch (f->command) {
> + case TC_BLOCK_BIND:
> + return tcf_block_cb_register(f->block, cb, cb_ident, cb_priv,
> + f->extack);
> + case TC_BLOCK_UNBIND:
> + tcf_block_cb_unregister(f->block, cb, cb_ident);
> + return 0;
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +EXPORT_SYMBOL(tcf_setup_block_offload);
> +
> static struct rhashtable indr_setup_block_ht;
>
> struct tc_indr_block_dev {
This change is pretty much unrelated to the rest of the series, isn't
it? Can you please post it separately and make the series smaller
this way?
Perhaps tcf_setup_block_offload_simple() would be a good name for this
helper?
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Larry Finger @ 2019-07-05 23:26 UTC (permalink / raw)
To: Daniel Drake, Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team
In-Reply-To: <CAD8Lp44HLPgOU+Z+w4Pq6ukLjZv2hM0=uBL7pWzQp+RsdRgG6Q@mail.gmail.com>
On 7/4/19 10:44 PM, Daniel Drake wrote:
> On Wed, Jul 3, 2019 at 8:59 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>> My point is this seems to be very dongle dependent :( We have to be
>> careful not breaking it for some users while fixing it for others.
>
> Do you still have your device?
>
> Once we get to the point when you are happy with Chris's two patches
> here on a code review level, we'll reach out to other driver
> contributors plus people who previously complained about these types
> of problems, and see if we can get some wider testing.
>
> Larry, do you have these devices, can you help with testing too?
I have some of the devices, and I can help with the testing.
Larry
^ permalink raw reply
* Re: [PATCH 12/15 net-next,v2] net: flow_offload: make flow block callback list per-driver
From: Jakub Kicinski @ 2019-07-05 23:25 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-13-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:40 +0200, Pablo Neira Ayuso wrote:
> Remove the global flow_block_cb_list, replace it by per-driver list
> of flow block objects. This will make it easier later on to support
> for policy hardware offload of multiple subsystems.
>
> Suggested-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
I don't understand the need for a per driver list of callbacks.
Your concern seems to be that drivers will get confused by multiple
subsystems trying to bind blocks. We have a feature flag for TC
offloads, why can't netfilter have one too? Way simpler.
If I may comment on the patches in general this series is really hard
to follow. Changes are split into patches in a strange way, and the
number of things called some combination of block cb and list makes my
head hurt :/
^ permalink raw reply
* Re: [pull request][net-next V2 0/2] Mellanox, mlx5 updates 2019-07-04
From: David Miller @ 2019-07-05 23:24 UTC (permalink / raw)
To: saeedm; +Cc: netdev, tariqt
In-Reply-To: <20190704205050.3354-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Thu, 4 Jul 2019 20:51:22 +0000
> This series adds the support for devlink fw query in mlx5
>
> Please pull and let me know if there is any problem.
>
> Please note that the series starts with a merge of mlx5-next branch,
> to resolve and avoid dependency with rdma tree.
> This what was actually missing from my previous submission of the 2
> devlink patches.
>
> v1->v2:
> - Removed the TLS patches from the pull request and will post them as a
> standalone series for Jakub to review.
Pulled.
^ permalink raw reply
* Re: [PATCH net] ipv4: Fix NULL pointer dereference in ipv4_neigh_lookup()
From: David Miller @ 2019-07-05 23:19 UTC (permalink / raw)
To: idosch; +Cc: netdev, dsahern, jiri, shalomt, mlxsw, idosch
In-Reply-To: <20190704162638.17913-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 4 Jul 2019 19:26:38 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Both ip_neigh_gw4() and ip_neigh_gw6() can return either a valid pointer
> or an error pointer, but the code currently checks that the pointer is
> not NULL.
>
> Fix this by checking that the pointer is not an error pointer, as this
> can result in a NULL pointer dereference [1]. Specifically, I believe
> that what happened is that ip_neigh_gw4() returned '-EINVAL'
> (0xffffffffffffffea) to which the offset of 'refcnt' (0x70) was added,
> which resulted in the address 0x000000000000005a.
>
> [1]
...
> Fixes: 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Shalom Toledo <shalomt@mellanox.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 6/7] nfp: Use spinlock_t instead of struct spinlock
From: David Miller @ 2019-07-05 23:18 UTC (permalink / raw)
To: bigeasy; +Cc: linux-kernel, tglx, peterz, jakub.kicinski, oss-drivers, netdev
In-Reply-To: <20190704153803.12739-7-bigeasy@linutronix.de>
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Thu, 4 Jul 2019 17:38:02 +0200
> For spinlocks the type spinlock_t should be used instead of "struct
> spinlock".
>
> Use spinlock_t for spinlock's definition.
>
> Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: oss-drivers@netronome.com
> Cc: netdev@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:58 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> @@ -1052,12 +1145,19 @@ static int tcf_block_offload_cmd(struct tcf_block *block,
> struct netlink_ext_ack *extack)
> {
> struct tc_block_offload bo = {};
> + int err;
>
> bo.command = command;
> bo.binder_type = ei->binder_type;
> bo.block = block;
> bo.extack = extack;
> - return dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + INIT_LIST_HEAD(&bo.cb_list);
> +
> + err = dev->netdev_ops->ndo_setup_tc(dev, TC_SETUP_BLOCK, &bo);
> + if (err < 0)
> + return err;
> +
> + return tcf_block_setup(block, &bo);
If this fails nothing will undo the old ndo call, no?
> }
>
> static int tcf_block_offload_bind(struct tcf_block *block, struct Qdisc *q,
^ permalink raw reply
* Re: [net-next, PATCH, v2] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:45 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562251569-16506-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:46:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> ---
>
> Changes since V1:
> - Make the code more readable
Ooops, I applied v1. Could you please send me any changes still necessary
relative to that?
Thanks.
^ permalink raw reply
* Re: [PATCH 12/15 net-next,v2] net: flow_offload: make flow block callback list per-driver
From: Jakub Kicinski @ 2019-07-05 22:42 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-13-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:40 +0200, Pablo Neira Ayuso wrote:
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/cls.c b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> index 96b89a7c468b..a42f92318b7a 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/cls.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/cls.c
> @@ -262,9 +262,12 @@ static int nfp_abm_setup_tc_block_cb(enum tc_setup_type type,
> }
> }
>
> +static LIST_HEAD(nfp_abm_vf_block_cb_list);
s/_vf//
> int nfp_abm_setup_cls_block(struct net_device *netdev, struct nfp_repr *repr,
> struct flow_block_offload *f)
> {
> - return flow_block_setup_offload(f, nfp_abm_setup_tc_block_cb,
> + return flow_block_setup_offload(f, &nfp_abm_block_cb_list,
> + nfp_abm_setup_tc_block_cb,
> repr, repr, true);
> }
> diff --git a/drivers/net/ethernet/netronome/nfp/bpf/main.c b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> index 3897cc4f7a7e..5316d85261c0 100644
> --- a/drivers/net/ethernet/netronome/nfp/bpf/main.c
> +++ b/drivers/net/ethernet/netronome/nfp/bpf/main.c
> @@ -160,6 +160,8 @@ static int nfp_bpf_setup_tc_block_cb(enum tc_setup_type type,
> return 0;
> }
>
> +static LIST_HEAD(nfp_bfp_block_cb_list);
s/bfp/bpf/
> static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> enum tc_setup_type type, void *type_data)
> {
> @@ -168,6 +170,7 @@ static int nfp_bpf_setup_tc(struct nfp_app *app, struct net_device *netdev,
> switch (type) {
> case TC_SETUP_BLOCK:
> return flow_block_setup_offload(type_data,
> + &nfp_bfp_block_cb_list,
> nfp_bpf_setup_tc_block_cb,
> nn, nn, true);
> default:
^ permalink raw reply
* Re: [PATCH] net: netsec: Sync dma for device on buffer allocation
From: David Miller @ 2019-07-05 22:42 UTC (permalink / raw)
To: ilias.apalodimas; +Cc: netdev, jaswinder.singh, ard.biesheuvel, arnd
In-Reply-To: <1562249469-14807-1-git-send-email-ilias.apalodimas@linaro.org>
From: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Date: Thu, 4 Jul 2019 17:11:09 +0300
> Quoting Arnd,
>
> We have to do a sync_single_for_device /somewhere/ before the
> buffer is given to the device. On a non-cache-coherent machine with
> a write-back cache, there may be dirty cache lines that get written back
> after the device DMA's data into it (e.g. from a previous memset
> from before the buffer got freed), so you absolutely need to flush any
> dirty cache lines on it first.
>
> Since the coherency is configurable in this device make sure we cover
> all configurations by explicitly syncing the allocated buffer for the
> device before refilling it's descriptors
>
> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Please make it explicit in your Subject lines which tree a patch is
for, in this case it should have been "[PATCH net-next] ".
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] net: hns3: some cleanups & bugfixes
From: David Miller @ 2019-07-05 22:39 UTC (permalink / raw)
To: tanhuazhong; +Cc: netdev, linux-kernel, salil.mehta, yisen.zhuang, linuxarm
In-Reply-To: <1562249068-40176-1-git-send-email-tanhuazhong@huawei.com>
From: Huazhong Tan <tanhuazhong@huawei.com>
Date: Thu, 4 Jul 2019 22:04:19 +0800
> This patch-set includes cleanups and bugfixes for
> the HNS3 ethernet controller driver.
>
> [patch 1/9] fixes VF's broadcast promisc mode not enabled after
> initializing.
>
> [patch 2/9] adds hints for fibre port not support flow control.
>
> [patch 3/9] fixes a port capbility updating issue.
>
> [patch 4/9 - 9/9] adds some cleanups for HNS3 driver.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] r8152: set RTL8152_UNPLUG only for real disconnection
From: David Miller @ 2019-07-05 22:38 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-288-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Thu, 4 Jul 2019 17:36:32 +0800
> Set the flag of RTL8152_UNPLUG if and only if the device is unplugged.
> Some error codes sometimes don't mean the real disconnection of usb device.
> For those situations, set the flag of RTL8152_UNPLUG causes the driver skips
> some flows of disabling the device, and it let the device stay at incorrect
> state.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied.
^ permalink raw reply
* Re: [PATCH 04/15 net-next,v2] net: sched: add tcf_block_setup()
From: Jakub Kicinski @ 2019-07-05 22:31 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netdev, netfilter-devel, davem, thomas.lendacky, f.fainelli,
ariel.elior, michael.chan, madalin.bucur, yisen.zhuang,
salil.mehta, jeffrey.t.kirsher, tariqt, saeedm, jiri, idosch,
peppe.cavallaro, grygorii.strashko, andrew, vivien.didelot,
alexandre.torgue, joabreu, linux-net-drivers, ogerlitz,
Manish.Chopra, marcelo.leitner, mkubecek, venkatkumar.duvvuru,
maxime.chevallier, cphealy
In-Reply-To: <20190704234843.6601-5-pablo@netfilter.org>
On Fri, 5 Jul 2019 01:48:32 +0200, Pablo Neira Ayuso wrote:
> +static int tcf_block_bind(struct tcf_block *block, struct tc_block_offload *bo)
> +{
> + struct tcf_block_cb *block_cb, *next;
> + int err, i = 0;
> +
> + list_for_each_entry(block_cb, &bo->cb_list, global_list) {
> + err = tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, true,
> + tcf_block_offload_in_use(block),
> + bo->extack);
> + if (err)
> + goto err_unroll;
> +
> + list_add(&block_cb->list, &block->cb_list);
> + i++;
> + }
> + list_splice(&bo->cb_list, &tcf_block_cb_list);
> +
> + return 0;
> +
> +err_unroll:
> + list_for_each_entry_safe(block_cb, next, &bo->cb_list, global_list) {
> + if (i-- > 0) {
> + list_del(&block_cb->list);
> + tcf_block_playback_offloads(block, block_cb->cb,
> + block_cb->cb_priv, false,
> + tcf_block_offload_in_use(block),
> + NULL);
> + }
> + kfree(block_cb);
Is this not a tcf_block_cb_free() on purpose?
> + }
> +
> + return err;
> +}
^ permalink raw reply
* Re: [PATCH][net-next] net: remove unused parameter from skb_checksum_try_convert
From: David Miller @ 2019-07-05 22:30 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1562231006-16341-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Thu, 4 Jul 2019 17:03:26 +0800
> the check parameter is never used
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/8] mlxsw: Enable/disable PTP shapers
From: David Miller @ 2019-07-05 22:29 UTC (permalink / raw)
To: idosch; +Cc: netdev, richardcochran, jiri, petrm, shalomt, mlxsw, idosch
In-Reply-To: <20190704070740.302-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 4 Jul 2019 10:07:32 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> Shalom says:
>
> In order to get more accurate hardware time stamping in Spectrum-1, the
> driver needs to apply a shaper on the port for speeds lower than 40Gbps.
> This shaper is called a PTP shaper and it is applied on hierarchy 0,
> which is the port hierarchy. This shaper may affect the shaper rates of
> all hierarchies.
>
> This patchset adds the ability to enable or disable the PTP shaper on
> the port in two scenarios:
> 1. When the user wants to enable/disable the hardware time stamping
> 2. When the port is brought up or down (including port speed change)
>
> Patch #1 adds the QEEC.ptps field that is used for enabling or disabling
> the PTP shaper on a port.
>
> Patch #2 adds a note about disabling the PTP shaper when calling to
> mlxsw_sp_port_ets_maxrate_set().
>
> Patch #3 adds the QPSC register that is responsible for configuring the
> PTP shaper parameters per speed.
>
> Patch #4 sets the PTP shaper parameters during the ptp_init().
>
> Patch #5 adds new operation for getting the port's speed.
>
> Patch #6 enables/disables the PTP shaper when turning on or off the
> hardware time stamping.
>
> Patch #7 enables/disables the PTP shaper when the port's status has
> changed (including port speed change).
>
> Patch #8 applies the PTP shaper enable/disable logic by filling the PTP
> shaper parameters array.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: socionext: remove set but not used variable 'pkts'
From: David Miller @ 2019-07-05 22:28 UTC (permalink / raw)
To: yuehaibing
Cc: jaswinder.singh, ast, ilias.apalodimas, daniel, jakub.kicinski,
hawk, netdev, xdp-newbies, bpf, kernel-janitors
In-Reply-To: <20190704033745.1758-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Thu, 4 Jul 2019 03:37:45 +0000
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/ethernet/socionext/netsec.c: In function 'netsec_clean_tx_dring':
> drivers/net/ethernet/socionext/netsec.c:637:15: warning:
> variable 'pkts' set but not used [-Wunused-but-set-variable]
>
> It is not used since commit ba2b232108d3 ("net: netsec: add XDP support")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] net: ethernet: allwinner: Remove unneeded memset
From: David Miller @ 2019-07-05 22:26 UTC (permalink / raw)
To: hariprasad.kelam
Cc: maxime.ripard, wens, ynezz, f.fainelli, andrew, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190704025906.GA20005@hari-Inspiron-1545>
From: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Date: Thu, 4 Jul 2019 08:29:06 +0530
> Remove unneeded memset as alloc_etherdev is using kvzalloc which uses
> __GFP_ZERO flag
>
> Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Applied.
^ permalink raw reply
* Re: linux-next: Tree for Jun 28 (kernel/bpf/cgroup.c)
From: Randy Dunlap @ 2019-07-05 22:23 UTC (permalink / raw)
To: Stephen Rothwell, Linux Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org, Daniel Mack,
Daniel Borkmann, Song Liu, Yonghong Song, bpf, Martin KaFai Lau,
Alexei Starovoitov
In-Reply-To: <74534ab8-a397-ac4f-dd02-9b3618d7c4cd@infradead.org>
On 6/28/19 1:52 PM, Randy Dunlap wrote:
> On 6/28/19 3:38 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> Changes since 20190627:
>>
>
> on i386:
>
> ld: kernel/bpf/cgroup.o: in function `cg_sockopt_func_proto':
> cgroup.c:(.text+0x2906): undefined reference to `bpf_sk_storage_delete_proto'
> ld: cgroup.c:(.text+0x2939): undefined reference to `bpf_sk_storage_get_proto'
> ld: kernel/bpf/cgroup.o: in function `__cgroup_bpf_run_filter_setsockopt':
> cgroup.c:(.text+0x85e4): undefined reference to `lock_sock_nested'
> ld: cgroup.c:(.text+0x8af2): undefined reference to `release_sock'
> ld: kernel/bpf/cgroup.o: in function `__cgroup_bpf_run_filter_getsockopt':
> cgroup.c:(.text+0x8fd6): undefined reference to `lock_sock_nested'
> ld: cgroup.c:(.text+0x94e4): undefined reference to `release_sock'
>
>
> Full randconfig file is attached.
>
These build errors still happen in linux-next of 20190705...
--
~Randy
^ permalink raw reply
* Re: [Patch net 0/3] hsr: a few bug fixes
From: David Miller @ 2019-07-05 22:22 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, arvid.brodin
In-Reply-To: <20190704002114.29004-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 3 Jul 2019 17:21:11 -0700
> This patchset contains 3 bug fixes for hsr triggered by a syzbot
> reproducer, please check each patch for details.
>
> Cc: Arvid Brodin <arvid.brodin@alten.se>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: add test_tcp_rtt to .gitignore
From: Daniel Borkmann @ 2019-07-05 22:21 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast, Andrii Nakryiko
In-Reply-To: <20190703200952.159728-1-sdf@google.com>
On 07/03/2019 10:09 PM, Stanislav Fomichev wrote:
> Forgot to add it in the original patch.
>
> Fixes: b55873984dab ("selftests/bpf: test BPF_SOCK_OPS_RTT_CB")
> Reported-by: Andrii Nakryiko <andriin@fb.com>
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf-next] selftests/bpf: fix test_align liveliness expectations
From: Daniel Borkmann @ 2019-07-05 22:21 UTC (permalink / raw)
To: Stanislav Fomichev, netdev, bpf; +Cc: davem, ast
In-Reply-To: <20190703212907.189141-1-sdf@google.com>
On 07/03/2019 11:29 PM, Stanislav Fomichev wrote:
> Commit 2589726d12a1 ("bpf: introduce bounded loops") caused a change
> in the way some registers liveliness is reported in the test_align.
> Add missing "_w" to a couple of tests. Note, there are no offset
> changes!
>
> Fixes: 2589726d12a1 ("bpf: introduce bounded loops")
> Signed-off-by: Stanislav Fomichev <sdf@google.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next 1/3] ipv4: Multipath hashing on inner L3 needs to consider inner IPv6 pkts
From: David Miller @ 2019-07-05 22:19 UTC (permalink / raw)
To: ssuryaextr; +Cc: netdev, idosch, nikolay, dsahern
In-Reply-To: <20190703151934.9567-2-ssuryaextr@gmail.com>
From: Stephen Suryaputra <ssuryaextr@gmail.com>
Date: Wed, 3 Jul 2019 11:19:32 -0400
> Commit 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts
> for GRE tunnel") supports multipath policy value of 2, Layer 3 or inner
> Layer 3 if present, but it only considers inner IPv4. There is a use
> case of IPv6 over GRE over IPv4, thus add the ability to hash on inner
> IPv6 addresses.
>
> Fixes: 363887a2cdfe ("ipv4: Support multipath hashing on inner IP pkts for GRE tunnel")
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
The wording in this commit message is very confusing.
If you say "IPv6 over GRE over IPv4" then IPv6 is the outer protocol
type, not the inner one.
You need to clarify or reword this commit message so that it is
understandable and matches the logic.
Thanks.
^ 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