* [PATCH net] net: stmmac: Set DMA buffer size in HW
From: Jose Abreu @ 2018-06-27 14:03 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
This is clearly a bug.
We need to set the DMA buffer size in the HW otherwise corruption can
occur when receiving packets.
This is probably not occuring because of small MTU values and because HW
has a default value internally (which currently is bigger than default
buffer size).
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Vitor Soares <soares@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 12 ++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h | 2 ++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 3 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 ++
4 files changed, 19 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index d37f17ca62fe..65bc3556bd8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -407,6 +407,16 @@ static void dwmac4_enable_tso(void __iomem *ioaddr, bool en, u32 chan)
}
}
+static void dwmac4_set_bfsize(void __iomem *ioaddr, int bfsize, u32 chan)
+{
+ u32 value = readl(ioaddr + DMA_CHAN_RX_CONTROL(chan));
+
+ value &= ~DMA_RBSZ_MASK;
+ value |= (bfsize << DMA_RBSZ_SHIFT) & DMA_RBSZ_MASK;
+
+ writel(value, ioaddr + DMA_CHAN_RX_CONTROL(chan));
+}
+
const struct stmmac_dma_ops dwmac4_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
@@ -431,6 +441,7 @@ const struct stmmac_dma_ops dwmac4_dma_ops = {
.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
.enable_tso = dwmac4_enable_tso,
+ .set_bfsize = dwmac4_set_bfsize,
};
const struct stmmac_dma_ops dwmac410_dma_ops = {
@@ -457,4 +468,5 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
.enable_tso = dwmac4_enable_tso,
+ .set_bfsize = dwmac4_set_bfsize,
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
index c63c1fe3f26b..22a4a6dbb1a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
@@ -120,6 +120,8 @@
/* DMA Rx Channel X Control register defines */
#define DMA_CONTROL_SR BIT(0)
+#define DMA_RBSZ_MASK GENMASK(14, 1)
+#define DMA_RBSZ_SHIFT 1
/* Interrupt status per channel */
#define DMA_CHAN_STATUS_REB GENMASK(21, 19)
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index e44e7b26ce82..fe8b536b13f8 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -183,6 +183,7 @@ struct stmmac_dma_ops {
void (*set_rx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
void (*set_tx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
void (*enable_tso)(void __iomem *ioaddr, bool en, u32 chan);
+ void (*set_bfsize)(void __iomem *ioaddr, int bfsize, u32 chan);
};
#define stmmac_reset(__priv, __args...) \
@@ -235,6 +236,8 @@ struct stmmac_dma_ops {
stmmac_do_void_callback(__priv, dma, set_tx_tail_ptr, __args)
#define stmmac_enable_tso(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, enable_tso, __args)
+#define stmmac_set_dma_bfsize(__priv, __args...) \
+ stmmac_do_void_callback(__priv, dma, set_bfsize, __args)
struct mac_device_info;
struct net_device;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index cba46b62a1cd..60f59abab009 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -1804,6 +1804,8 @@ static void stmmac_dma_operation_mode(struct stmmac_priv *priv)
stmmac_dma_rx_mode(priv, priv->ioaddr, rxmode, chan,
rxfifosz, qmode);
+ stmmac_set_dma_bfsize(priv, priv->ioaddr, priv->dma_buf_sz,
+ chan);
}
for (chan = 0; chan < tx_channels_count; chan++) {
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v2 net-next 01/12] net: core: trivial netif_receive_skb_list() entry point
From: Edward Cree @ 2018-06-27 14:03 UTC (permalink / raw)
To: Eric Dumazet, linux-net-drivers, netdev; +Cc: davem
In-Reply-To: <3fbb875b-c737-1b23-d56f-816e667e1e7f@gmail.com>
On 27/06/18 01:06, Eric Dumazet wrote:
> On 06/26/2018 11:17 AM, Edward Cree wrote:
>> Just calls netif_receive_skb() in a loop.
> ...
>
>> +void netif_receive_skb_list(struct sk_buff_head *list)
>
> Please use a standard list_head and standard list operators.
>
> (In all your patches)
>
> 1) We do not want to carry a spinlock_t + count per list...
>
> 2) We get nice debugging features with CONFIG_DEBUG_LIST=y
>
> Note that we now have skb->list after
> commit d4546c2509b1e9cd082e3682dcec98472e37ee5a ("net: Convert GRO SKB handling to list_head.")
So we do. That hadn't gone in yet on Monday when I last pulled net-next; I'll make sure to use it in the next spin.
Thanks.
^ permalink raw reply
* Re: [PATCH net] net: stmmac: Set DMA buffer size in HW
From: Jose Abreu @ 2018-06-27 14:11 UTC (permalink / raw)
To: netdev, David S. Miller
Cc: Joao Pinto, Vitor Soares, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <2447baa54f044c9c8a1674970061ac4ac9a25e49.1530108148.git.joabreu@synopsys.com>
David,
On 27-06-2018 15:03, Jose Abreu wrote:
> This is clearly a bug.
You will probably have an hard time backporting this because of
the way the callbacks are handled now.
I can send you a patch based on some -stable branch if you prefer.
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: kbuild test robot @ 2018-06-27 14:15 UTC (permalink / raw)
To: Jose Abreu
Cc: kbuild-all, netdev, Jose Abreu, David S. Miller, Joao Pinto,
Vitor Soares, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <daa3124702201f0d1c30da51f2a90cf432e39ba3.1530103308.git.joabreu@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 4313 bytes --]
Hi Jose,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jose-Abreu/net-stmmac-Add-support-for-CBS-QDISC/20180627-214704
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=sh
All warnings (new ones prefixed by >>):
In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:174,
from include/linux/list.h:9,
from include/linux/timer.h:5,
from include/linux/workqueue.h:9,
from include/net/pkt_cls.h:6,
from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
do_div(value, speed_div);
^~~~~~
include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:329:2: note: in expansion of macro 'do_div'
do_div(value, speed_div);
^~~~~~
vim +/do_div +325 drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c
291
292 static int tc_setup_cbs(struct stmmac_priv *priv,
293 struct tc_cbs_qopt_offload *qopt)
294 {
295 u32 tx_queues_count = priv->plat->tx_queues_to_use;
296 u32 queue = qopt->queue;
297 u32 ptr, speed_div;
298 u32 mode_to_use;
299 s64 value;
300 int ret;
301
302 /* Queue 0 is not AVB capable */
303 if (queue <= 0 || queue >= tx_queues_count)
304 return -EINVAL;
305 if (priv->speed != SPEED_100 && priv->speed != SPEED_1000)
306 return -EOPNOTSUPP;
307
308 mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
309 if (mode_to_use == MTL_QUEUE_DCB && qopt->enable) {
310 ret = stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_AVB);
311 if (ret)
312 return ret;
313
314 priv->plat->tx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
315 } else if (!qopt->enable) {
316 return stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_DCB);
317 }
318
319 /* Port Transmit Rate and Speed Divider */
320 ptr = (priv->speed == SPEED_100) ? 4 : 8;
321 speed_div = (priv->speed == SPEED_100) ? 100000 : 1000000;
322
323 /* Final adjustments for HW */
324 value = qopt->idleslope * 1024 * ptr;
> 325 do_div(value, speed_div);
326 priv->plat->tx_queues_cfg[queue].idle_slope = value & GENMASK(31, 0);
327
328 value = -qopt->sendslope * 1024UL * ptr;
329 do_div(value, speed_div);
330 priv->plat->tx_queues_cfg[queue].send_slope = value & GENMASK(31, 0);
331
332 value = qopt->hicredit * 1024 * 8;
333 priv->plat->tx_queues_cfg[queue].high_credit = value & GENMASK(31, 0);
334
335 value = qopt->locredit * 1024 * 8;
336 priv->plat->tx_queues_cfg[queue].low_credit = value & GENMASK(31, 0);
337
338 ret = stmmac_config_cbs(priv, priv->hw,
339 priv->plat->tx_queues_cfg[queue].send_slope,
340 priv->plat->tx_queues_cfg[queue].idle_slope,
341 priv->plat->tx_queues_cfg[queue].high_credit,
342 priv->plat->tx_queues_cfg[queue].low_credit,
343 queue);
344 if (ret)
345 return ret;
346
347 dev_info(priv->device, "CBS queue %d: send %d, idle %d, hi %d, lo %d\n",
348 queue, qopt->sendslope, qopt->idleslope,
349 qopt->hicredit, qopt->locredit);
350 return 0;
351 }
352
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 48915 bytes --]
^ permalink raw reply
* Re: [RFC bpf-next 2/6] net: xdp: RX meta data infrastructure
From: Jesper Dangaard Brouer @ 2018-06-27 14:15 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Alexei Starovoitov, Daniel Borkmann, neerav.parikh, pjwaskiewicz,
ttoukan.linux, Tariq Toukan, alexander.h.duyck,
peter.waskiewicz.jr, Opher Reviv, Rony Efraim, netdev,
Saeed Mahameed, brouer
In-Reply-To: <20180627024615.17856-3-saeedm@mellanox.com>
On Tue, 26 Jun 2018 19:46:11 -0700
Saeed Mahameed <saeedm@dev.mellanox.co.il> wrote:
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 2deea7166a34..afe302613ae1 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -138,6 +138,12 @@ xdp_set_data_meta_invalid(struct xdp_buff *xdp)
> xdp->data_meta = xdp->data + 1;
> }
>
> +static __always_inline void
> +xdp_reset_data_meta(struct xdp_buff *xdp)
> +{
> + xdp->data_meta = xdp->data_hard_start;
> +}
This is WRONG ... it should be:
xdp->data_meta = xdp->data;
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH v2 net-next 1/2] netfilter: check if the socket netns is correct.
From: Florian Westphal @ 2018-06-27 14:22 UTC (permalink / raw)
To: Flavio Leitner
Cc: netdev, Eric Dumazet, Paolo Abeni, David Miller, Florian Westphal,
netfilter-devel
In-Reply-To: <20180627133426.3858-2-fbl@redhat.com>
Flavio Leitner <fbl@redhat.com> wrote:
> Netfilter assumes that if the socket is present in the skb, then
> it can be used because that reference is cleaned up while the skb
> is crossing netns.
>
> We want to change that to preserve the socket reference in a future
> patch, so this is a preparation updating netfilter to check if the
> socket netns matches before use it.
Acked-by: Florian Westphal <fw@strlen.de>
^ permalink raw reply
* Re: [PATCH net-next v2] net: vhost: improve performance when enable busyloop
From: Jason Wang @ 2018-06-27 14:24 UTC (permalink / raw)
To: xiangxia.m.yue; +Cc: virtualization, netdev, Tonghao Zhang, Michael S. Tsirkin
In-Reply-To: <1529990276-61157-1-git-send-email-xiangxia.m.yue@gmail.com>
On 2018年06月26日 13:17, xiangxia.m.yue@gmail.com wrote:
> From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
>
> This patch improves the guest receive performance from
> host. On the handle_tx side, we poll the sock receive
> queue at the same time. handle_rx do that in the same way.
>
> For avoiding deadlock, change the code to lock the vq one
> by one and use the VHOST_NET_VQ_XX as a subclass for
> mutex_lock_nested. With the patch, qemu can set differently
> the busyloop_timeout for rx or tx queue.
>
> We set the poll-us=100us and use the iperf3 to test
> its throughput. The iperf3 command is shown as below.
>
> on the guest:
> iperf3 -s -D
>
> on the host:
> iperf3 -c 192.168.1.100 -i 1 -P 10 -t 10 -M 1400
>
> * With the patch: 23.1 Gbits/sec
> * Without the patch: 12.7 Gbits/sec
>
> Signed-off-by: Tonghao Zhang <zhangtonghao@didichuxing.com>
Thanks a lot for the patch. Looks good generally, but please split this
big patch into separate ones like:
patch 1: lock vqs one by one
patch 2: replace magic number of lock annotation
patch 3: factor out generic busy polling logic to vhost_net_busy_poll()
patch 4: add rx busy polling in tx path.
And please cc Michael in v3.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: Jose Abreu @ 2018-06-27 14:32 UTC (permalink / raw)
To: kbuild test robot, Jose Abreu, linux-sh, Rich Felker,
Yoshinori Sato
Cc: kbuild-all, netdev, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <201806272221.VPR2vJhr%fengguang.wu@intel.com>
++ SH Maintainers
++ SH ML
Hi SH Maintainers,
On 27-06-2018 15:15, kbuild test robot wrote:
> Hi Jose,
>
> I love your patch! Perhaps something to improve:
>
> [auto build test WARNING on net-next/master]
>
> url: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Jose-2DAbreu_net-2Dstmmac-2DAdd-2Dsupport-2Dfor-2DCBS-2DQDISC_20180627-2D214704&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=qW5_vbinGt0OnyDfQ2wtKdb2ZGzCcLwq6Fmlaki61xw&e=
> config: sh-allyesconfig (attached as .config)
> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=4nNar4fgVZq0LjrPKIZP30nxVUY4yeu5QeyKbmlsu8A&e= -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.2.0 make.cross ARCH=sh
>
> All warnings (new ones prefixed by >>):
>
> In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
> from include/linux/kernel.h:174,
> from include/linux/list.h:9,
> from include/linux/timer.h:5,
> from include/linux/workqueue.h:9,
> from include/net/pkt_cls.h:6,
> from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> ^
>>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
> do_div(value, speed_div);
> ^~~~~~
> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
I'm not seeing the reason for this warning as I'm using a 64 bit
var. I guess the warning is appearing only because its signed
[see source bellow]. Is this not supported?
Thanks and Best Regards,
Jose Miguel Abreu
> ^
> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:329:2: note: in expansion of macro 'do_div'
> do_div(value, speed_div);
> ^~~~~~
>
> vim +/do_div +325 drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c
>
> 291
> 292 static int tc_setup_cbs(struct stmmac_priv *priv,
> 293 struct tc_cbs_qopt_offload *qopt)
> 294 {
> 295 u32 tx_queues_count = priv->plat->tx_queues_to_use;
> 296 u32 queue = qopt->queue;
> 297 u32 ptr, speed_div;
> 298 u32 mode_to_use;
> 299 s64 value;
> 300 int ret;
> 301
> 302 /* Queue 0 is not AVB capable */
> 303 if (queue <= 0 || queue >= tx_queues_count)
> 304 return -EINVAL;
> 305 if (priv->speed != SPEED_100 && priv->speed != SPEED_1000)
> 306 return -EOPNOTSUPP;
> 307
> 308 mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
> 309 if (mode_to_use == MTL_QUEUE_DCB && qopt->enable) {
> 310 ret = stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_AVB);
> 311 if (ret)
> 312 return ret;
> 313
> 314 priv->plat->tx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
> 315 } else if (!qopt->enable) {
> 316 return stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_DCB);
> 317 }
> 318
> 319 /* Port Transmit Rate and Speed Divider */
> 320 ptr = (priv->speed == SPEED_100) ? 4 : 8;
> 321 speed_div = (priv->speed == SPEED_100) ? 100000 : 1000000;
> 322
> 323 /* Final adjustments for HW */
> 324 value = qopt->idleslope * 1024 * ptr;
> > 325 do_div(value, speed_div);
> 326 priv->plat->tx_queues_cfg[queue].idle_slope = value & GENMASK(31, 0);
> 327
> 328 value = -qopt->sendslope * 1024UL * ptr;
> 329 do_div(value, speed_div);
> 330 priv->plat->tx_queues_cfg[queue].send_slope = value & GENMASK(31, 0);
> 331
> 332 value = qopt->hicredit * 1024 * 8;
> 333 priv->plat->tx_queues_cfg[queue].high_credit = value & GENMASK(31, 0);
> 334
> 335 value = qopt->locredit * 1024 * 8;
> 336 priv->plat->tx_queues_cfg[queue].low_credit = value & GENMASK(31, 0);
> 337
> 338 ret = stmmac_config_cbs(priv, priv->hw,
> 339 priv->plat->tx_queues_cfg[queue].send_slope,
> 340 priv->plat->tx_queues_cfg[queue].idle_slope,
> 341 priv->plat->tx_queues_cfg[queue].high_credit,
> 342 priv->plat->tx_queues_cfg[queue].low_credit,
> 343 queue);
> 344 if (ret)
> 345 return ret;
> 346
> 347 dev_info(priv->device, "CBS queue %d: send %d, idle %d, hi %d, lo %d\n",
> 348 queue, qopt->sendslope, qopt->idleslope,
> 349 qopt->hicredit, qopt->locredit);
> 350 return 0;
> 351 }
> 352
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_kbuild-2Dall&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=yMjbhyNoi6ZESIohHtaqFOTXipZVefU7mA4Tfc5QPms&e= Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: Jose Abreu @ 2018-06-27 14:36 UTC (permalink / raw)
To: kbuild test robot, Jose Abreu, linux-sh, Rich Felker,
Yoshinori Sato, linux-kernel@vger.kernel.org
Cc: kbuild-all, netdev, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <3780919b-c9ce-2ab6-be3a-376752c608ac@synopsys.com>
++ LKML because I just noticed this is using generic headers.
On 27-06-2018 15:32, Jose Abreu wrote:
> ++ SH Maintainers
> ++ SH ML
>
> Hi SH Maintainers,
>
> On 27-06-2018 15:15, kbuild test robot wrote:
>> Hi Jose,
>>
>> I love your patch! Perhaps something to improve:
>>
>> [auto build test WARNING on net-next/master]
>>
>> url: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Jose-2DAbreu_net-2Dstmmac-2DAdd-2Dsupport-2Dfor-2DCBS-2DQDISC_20180627-2D214704&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=qW5_vbinGt0OnyDfQ2wtKdb2ZGzCcLwq6Fmlaki61xw&e=
>> config: sh-allyesconfig (attached as .config)
>> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>> reproduce:
>> wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=4nNar4fgVZq0LjrPKIZP30nxVUY4yeu5QeyKbmlsu8A&e= -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> GCC_VERSION=7.2.0 make.cross ARCH=sh
>>
>> All warnings (new ones prefixed by >>):
>>
>> In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
>> from include/linux/kernel.h:174,
>> from include/linux/list.h:9,
>> from include/linux/timer.h:5,
>> from include/linux/workqueue.h:9,
>> from include/net/pkt_cls.h:6,
>> from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>> ^
>>>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
>> do_div(value, speed_div);
>> ^~~~~~
>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> I'm not seeing the reason for this warning as I'm using a 64 bit
> var. I guess the warning is appearing only because its signed
> [see source bellow]. Is this not supported?
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
>> ^
>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:329:2: note: in expansion of macro 'do_div'
>> do_div(value, speed_div);
>> ^~~~~~
>>
>> vim +/do_div +325 drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c
>>
>> 291
>> 292 static int tc_setup_cbs(struct stmmac_priv *priv,
>> 293 struct tc_cbs_qopt_offload *qopt)
>> 294 {
>> 295 u32 tx_queues_count = priv->plat->tx_queues_to_use;
>> 296 u32 queue = qopt->queue;
>> 297 u32 ptr, speed_div;
>> 298 u32 mode_to_use;
>> 299 s64 value;
>> 300 int ret;
>> 301
>> 302 /* Queue 0 is not AVB capable */
>> 303 if (queue <= 0 || queue >= tx_queues_count)
>> 304 return -EINVAL;
>> 305 if (priv->speed != SPEED_100 && priv->speed != SPEED_1000)
>> 306 return -EOPNOTSUPP;
>> 307
>> 308 mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
>> 309 if (mode_to_use == MTL_QUEUE_DCB && qopt->enable) {
>> 310 ret = stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_AVB);
>> 311 if (ret)
>> 312 return ret;
>> 313
>> 314 priv->plat->tx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
>> 315 } else if (!qopt->enable) {
>> 316 return stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_DCB);
>> 317 }
>> 318
>> 319 /* Port Transmit Rate and Speed Divider */
>> 320 ptr = (priv->speed == SPEED_100) ? 4 : 8;
>> 321 speed_div = (priv->speed == SPEED_100) ? 100000 : 1000000;
>> 322
>> 323 /* Final adjustments for HW */
>> 324 value = qopt->idleslope * 1024 * ptr;
>> > 325 do_div(value, speed_div);
>> 326 priv->plat->tx_queues_cfg[queue].idle_slope = value & GENMASK(31, 0);
>> 327
>> 328 value = -qopt->sendslope * 1024UL * ptr;
>> 329 do_div(value, speed_div);
>> 330 priv->plat->tx_queues_cfg[queue].send_slope = value & GENMASK(31, 0);
>> 331
>> 332 value = qopt->hicredit * 1024 * 8;
>> 333 priv->plat->tx_queues_cfg[queue].high_credit = value & GENMASK(31, 0);
>> 334
>> 335 value = qopt->locredit * 1024 * 8;
>> 336 priv->plat->tx_queues_cfg[queue].low_credit = value & GENMASK(31, 0);
>> 337
>> 338 ret = stmmac_config_cbs(priv, priv->hw,
>> 339 priv->plat->tx_queues_cfg[queue].send_slope,
>> 340 priv->plat->tx_queues_cfg[queue].idle_slope,
>> 341 priv->plat->tx_queues_cfg[queue].high_credit,
>> 342 priv->plat->tx_queues_cfg[queue].low_credit,
>> 343 queue);
>> 344 if (ret)
>> 345 return ret;
>> 346
>> 347 dev_info(priv->device, "CBS queue %d: send %d, idle %d, hi %d, lo %d\n",
>> 348 queue, qopt->sendslope, qopt->idleslope,
>> 349 qopt->hicredit, qopt->locredit);
>> 350 return 0;
>> 351 }
>> 352
>>
>> ---
>> 0-DAY kernel test infrastructure Open Source Technology Center
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.01.org_pipermail_kbuild-2Dall&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=yMjbhyNoi6ZESIohHtaqFOTXipZVefU7mA4Tfc5QPms&e= Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: Geert Uytterhoeven @ 2018-06-27 14:36 UTC (permalink / raw)
To: Jose.Abreu
Cc: kbuild test robot, Linux-sh list, Rich Felker, Yoshinori Sato,
kbuild-all, netdev, David S. Miller, Joao.Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <3780919b-c9ce-2ab6-be3a-376752c608ac@synopsys.com>
Hi Jose,
On Wed, Jun 27, 2018 at 4:32 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
> ++ SH Maintainers
> ++ SH ML
>
> Hi SH Maintainers,
>
> On 27-06-2018 15:15, kbuild test robot wrote:
> > Hi Jose,
> >
> > I love your patch! Perhaps something to improve:
> >
> > [auto build test WARNING on net-next/master]
> >
> > url: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Jose-2DAbreu_net-2Dstmmac-2DAdd-2Dsupport-2Dfor-2DCBS-2DQDISC_20180627-2D214704&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=qW5_vbinGt0OnyDfQ2wtKdb2ZGzCcLwq6Fmlaki61xw&e=
> > config: sh-allyesconfig (attached as .config)
> > compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> > reproduce:
> > wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=4nNar4fgVZq0LjrPKIZP30nxVUY4yeu5QeyKbmlsu8A&e= -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > GCC_VERSION=7.2.0 make.cross ARCH=sh
> >
> > All warnings (new ones prefixed by >>):
> >
> > In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
> > from include/linux/kernel.h:174,
> > from include/linux/list.h:9,
> > from include/linux/timer.h:5,
> > from include/linux/workqueue.h:9,
> > from include/net/pkt_cls.h:6,
> > from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
> > drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
> > include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> > ^
> >>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
> > do_div(value, speed_div);
> > ^~~~~~
> > include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>
> I'm not seeing the reason for this warning as I'm using a 64 bit
> var. I guess the warning is appearing only because its signed
> [see source bellow]. Is this not supported?
No, the first parameter of do_div() must be u64, hence the check to
enforce that.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup
From: Willem de Bruijn @ 2018-06-27 14:36 UTC (permalink / raw)
To: ecree; +Cc: linux-net-drivers, Network Development, David Miller
In-Reply-To: <a665e6bc-176c-6c5a-282b-a3ed52e0a13f@solarflare.com>
On Tue, Jun 26, 2018 at 8:19 PM Edward Cree <ecree@solarflare.com> wrote:
>
> __netif_receive_skb_taps() does a depressingly large amount of per-packet
> work that can't easily be listified, because the another_round looping
> makes it nontrivial to slice up into smaller functions.
> Fortunately, most of that work disappears in the fast path:
> * Hardware devices generally don't have an rx_handler
> * Unless you're tcpdumping or something, there is usually only one ptype
> * VLAN processing comes before the protocol ptype lookup, so doesn't force
> a pt_prev deliver
> so normally, __netif_receive_skb_taps() will run straight through and return
> the one ptype found in ptype_base[hash of skb->protocol].
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
> ---
> -static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> +static int __netif_receive_skb_taps(struct sk_buff *skb, bool pfmemalloc,
> + struct packet_type **pt_prev)
A lot of code churn can be avoided by keeping local variable pt_prev and
calling this ppt_prev or so, then assigning just before returning on success.
Also, this function does more than just process network taps.
> {
> - struct packet_type *ptype, *pt_prev;
> rx_handler_func_t *rx_handler;
> struct net_device *orig_dev;
> bool deliver_exact = false;
> + struct packet_type *ptype;
> int ret = NET_RX_DROP;
> __be16 type;
>
> @@ -4514,7 +4515,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> skb_reset_transport_header(skb);
> skb_reset_mac_len(skb);
>
> - pt_prev = NULL;
> + *pt_prev = NULL;
>
> another_round:
> skb->skb_iif = skb->dev->ifindex;
> @@ -4535,25 +4536,25 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
> goto skip_taps;
>
> list_for_each_entry_rcu(ptype, &ptype_all, list) {
> - if (pt_prev)
> - ret = deliver_skb(skb, pt_prev, orig_dev);
> - pt_prev = ptype;
> + if (*pt_prev)
> + ret = deliver_skb(skb, *pt_prev, orig_dev);
> + *pt_prev = ptype;
> }
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: Jose Abreu @ 2018-06-27 14:44 UTC (permalink / raw)
To: Geert Uytterhoeven, Jose.Abreu
Cc: kbuild test robot, Linux-sh list, Rich Felker, Yoshinori Sato,
kbuild-all, netdev, David S. Miller, Joao.Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <CAMuHMdUhQBpfZGk-18F8BxPqRzHX4GEEV-=4LZ9NeO=pm6bsyg@mail.gmail.com>
Hi Geert,
On 27-06-2018 15:36, Geert Uytterhoeven wrote:
> Hi Jose,
>
> On Wed, Jun 27, 2018 at 4:32 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>> ++ SH Maintainers
>> ++ SH ML
>>
>> Hi SH Maintainers,
>>
>> On 27-06-2018 15:15, kbuild test robot wrote:
>>> Hi Jose,
>>>
>>> I love your patch! Perhaps something to improve:
>>>
>>> [auto build test WARNING on net-next/master]
>>>
>>> url: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Jose-2DAbreu_net-2Dstmmac-2DAdd-2Dsupport-2Dfor-2DCBS-2DQDISC_20180627-2D214704&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=qW5_vbinGt0OnyDfQ2wtKdb2ZGzCcLwq6Fmlaki61xw&e=
>>> config: sh-allyesconfig (attached as .config)
>>> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>> reproduce:
>>> wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=4nNar4fgVZq0LjrPKIZP30nxVUY4yeu5QeyKbmlsu8A&e= -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # save the attached .config to linux build tree
>>> GCC_VERSION=7.2.0 make.cross ARCH=sh
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>> In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
>>> from include/linux/kernel.h:174,
>>> from include/linux/list.h:9,
>>> from include/linux/timer.h:5,
>>> from include/linux/workqueue.h:9,
>>> from include/net/pkt_cls.h:6,
>>> from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
>>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
>>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
>>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>>> ^
>>>>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
>>> do_div(value, speed_div);
>>> ^~~~~~
>>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
>>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
>> I'm not seeing the reason for this warning as I'm using a 64 bit
>> var. I guess the warning is appearing only because its signed
>> [see source bellow]. Is this not supported?
> No, the first parameter of do_div() must be u64, hence the check to
> enforce that.
Hmm ok. I guess I can use two variables then because the only
case value will be negative is with locredit and this does not
need the do_div.
Thanks for the clarification.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [BUG] net: tg3: two possible data races
From: Siva Reddy Kallam @ 2018-06-27 14:46 UTC (permalink / raw)
To: Jia-Ju Bai
Cc: Prashant Sreedharan, Michael Chan, Linux Netdev List,
Linux Kernel Mailing List
On Wed, Jun 27, 2018 at 7:17 AM, Jia-Ju Bai <baijiaju1990@gmail.com> wrote:
> The call paths in Linux 4.16.7 that may raise the first data race:
>
> CPU0:
> tg3_open
> tg3_start
> line 11611: spin_lock_bh()
> tg3_enable_ints
> line 1023: tp->tnapi->last_tag [READ]
>
> CPU1:
> tg3_poll
> line 7341: tnapi->last_tag [WRITE]
>
> The READ operation in CPU0 is performed with holding a spinlock (line
> 11611), but the WRITE operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_poll().
>
> -----------------------------------------------------------------------
>
> The call paths in Linux 4.16.7 that may raise the second data race:
>
> CPU0:
> tg3_open
> tg3_start
> line 11611: spin_lock_bh()
> tg3_enable_ints
> line 1023: tp->irq_sync [WRITE]
>
> CPU1:
> tg3_interrupt_tagged
> tg3_irq_sync
> line 7341: tp->irq_sync [READ]
>
> The WRITE operation in CPU0 is performed with holding a spinlock (line
> 11611), but the READ operation in CPU1 is performed without holding this
> spinlock, so it may cause a data race here.
> A possible fix may be to add spin_lock_bh() in tg3_irq_sync().
>
> I am not sure that whether the possible fixes are correct, so I only report
> the data races.
>
>
> Best wishes,
> Jia-Ju Bai
>
>
We will evaluate this and provide an update on this.
^ permalink raw reply
* Re: [PATCH net-next] tcp: replace LINUX_MIB_TCPOFODROP with LINUX_MIB_TCPRMEMFULLDROP for drops due to receive buffer full
From: Eric Dumazet @ 2018-06-27 14:48 UTC (permalink / raw)
To: Yafang Shao, edumazet, davem; +Cc: netdev, linux-kernel
In-Reply-To: <1530100216-13070-1-git-send-email-laoar.shao@gmail.com>
On 06/27/2018 04:50 AM, Yafang Shao wrote:
> When sk_rmem_alloc is larger than the receive buffer and we can't
> schedule more memory for it, the skb will be dropped.
>
> In above situation, if this skb is put into the ofo queue,
> LINUX_MIB_TCPOFODROP is incremented to track it,
> while if this skb is put into the receive queue, there's no record.
>
> So LINUX_MIB_TCPOFODROP is replaced with LINUX_MIB_TCPRMEMFULLDROP to track
> this behavior.
Hi Yafang
I do not want to remove TCPOFODrop and mix multiple causes in one single counter.
Please take a look at commit a6df1ae9383697c to have the reasoning.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH v2 net-next 06/12] net: core: propagate SKB lists through packet_type lookup
From: Edward Cree @ 2018-06-27 14:49 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: linux-net-drivers, Network Development, David Miller
In-Reply-To: <CAF=yD-JANo1aq+pKqxzQi5g60Jc7Fkm75XJWpNHfhuzxFkK+iw@mail.gmail.com>
On 27/06/18 15:36, Willem de Bruijn wrote:
> On Tue, Jun 26, 2018 at 8:19 PM Edward Cree <ecree@solarflare.com> wrote:
>> __netif_receive_skb_taps() does a depressingly large amount of per-packet
>> work that can't easily be listified, because the another_round looping
>> makes it nontrivial to slice up into smaller functions.
>> Fortunately, most of that work disappears in the fast path:
>> * Hardware devices generally don't have an rx_handler
>> * Unless you're tcpdumping or something, there is usually only one ptype
>> * VLAN processing comes before the protocol ptype lookup, so doesn't force
>> a pt_prev deliver
>> so normally, __netif_receive_skb_taps() will run straight through and return
>> the one ptype found in ptype_base[hash of skb->protocol].
>>
>> Signed-off-by: Edward Cree <ecree@solarflare.com>
>> ---
>> -static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
>> +static int __netif_receive_skb_taps(struct sk_buff *skb, bool pfmemalloc,
>> + struct packet_type **pt_prev)
> A lot of code churn can be avoided by keeping local variable pt_prev and
> calling this ppt_prev or so, then assigning just before returning on success.
Good idea, I'll try that.
> Also, this function does more than just process network taps.
This is true, but naming things is hard, and I couldn't think of either a
better new name for this function or a name that could fit in between
__netif_receive_skb() and __netif_receive_skb_core() for the new function
in my patch named __netif_receive_skb_core(). Any suggestions?
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Add support for CBS QDISC
From: Geert Uytterhoeven @ 2018-06-27 14:51 UTC (permalink / raw)
To: Jose.Abreu
Cc: kbuild test robot, Linux-sh list, Rich Felker, Yoshinori Sato,
kbuild-all, netdev, David S. Miller, Joao.Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <222b400d-bc25-5854-370a-84d0d9056932@synopsys.com>
Hi Jose,
On Wed, Jun 27, 2018 at 4:44 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
> On 27-06-2018 15:36, Geert Uytterhoeven wrote:
> > On Wed, Jun 27, 2018 at 4:32 PM Jose Abreu <Jose.Abreu@synopsys.com> wrote:
> >> ++ SH Maintainers
> >> ++ SH ML
> >>
> >> Hi SH Maintainers,
> >>
> >> On 27-06-2018 15:15, kbuild test robot wrote:
> >>> Hi Jose,
> >>>
> >>> I love your patch! Perhaps something to improve:
> >>>
> >>> [auto build test WARNING on net-next/master]
> >>>
> >>> url: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_0day-2Dci_linux_commits_Jose-2DAbreu_net-2Dstmmac-2DAdd-2Dsupport-2Dfor-2DCBS-2DQDISC_20180627-2D214704&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=qW5_vbinGt0OnyDfQ2wtKdb2ZGzCcLwq6Fmlaki61xw&e=
> >>> config: sh-allyesconfig (attached as .config)
> >>> compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> >>> reproduce:
> >>> wget https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_intel_lkp-2Dtests_master_sbin_make.cross&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=YIae3rrFzqYg_5b4eVIAXuyvT_EV0vKACS25rJugux8&s=4nNar4fgVZq0LjrPKIZP30nxVUY4yeu5QeyKbmlsu8A&e= -O ~/bin/make.cross
> >>> chmod +x ~/bin/make.cross
> >>> # save the attached .config to linux build tree
> >>> GCC_VERSION=7.2.0 make.cross ARCH=sh
> >>>
> >>> All warnings (new ones prefixed by >>):
> >>>
> >>> In file included from ./arch/sh/include/generated/asm/div64.h:1:0,
> >>> from include/linux/kernel.h:174,
> >>> from include/linux/list.h:9,
> >>> from include/linux/timer.h:5,
> >>> from include/linux/workqueue.h:9,
> >>> from include/net/pkt_cls.h:6,
> >>> from drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:7:
> >>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c: In function 'tc_setup_cbs':
> >>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> >>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> >>> ^
> >>>>> drivers/net//ethernet/stmicro/stmmac/stmmac_tc.c:325:2: note: in expansion of macro 'do_div'
> >>> do_div(value, speed_div);
> >>> ^~~~~~
> >>> include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast
> >>> (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
> >> I'm not seeing the reason for this warning as I'm using a 64 bit
> >> var. I guess the warning is appearing only because its signed
> >> [see source bellow]. Is this not supported?
> > No, the first parameter of do_div() must be u64, hence the check to
> > enforce that.
>
> Hmm ok. I guess I can use two variables then because the only
> case value will be negative is with locredit and this does not
> need the do_div.
You can use div_s64_rem() or div_s64() (in include/linux/math64.h).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 3/3] virtio_net: split XDP_TX kick and XDP_REDIRECT map flushing
From: Jason Wang @ 2018-06-27 14:56 UTC (permalink / raw)
To: Jesper Dangaard Brouer, netdev
Cc: John Fastabend, Daniel Borkmann, BjörnTöpel,
Alexei Starovoitov
In-Reply-To: <153002759867.15389.3727307011205722452.stgit@firesoul>
On 2018年06月26日 23:39, Jesper Dangaard Brouer wrote:
> The driver was combining XDP_TX virtqueue_kick and XDP_REDIRECT
> map flushing (xdp_do_flush_map). This is suboptimal, these two
> flush operations should be kept separate.
>
> The suboptimal behavior was introduced in commit 9267c430c6b6
> ("virtio-net: add missing virtqueue kick when flushing packets").
>
> Fixes: 9267c430c6b6 ("virtio-net: add missing virtqueue kick when flushing packets")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
> drivers/net/virtio_net.c | 30 +++++++++++++++++++-----------
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 1619ee3070b6..ae47ecf80c2d 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -53,6 +53,10 @@ module_param(napi_tx, bool, 0644);
> /* Amount of XDP headroom to prepend to packets for use by xdp_adjust_head */
> #define VIRTIO_XDP_HEADROOM 256
>
> +/* Separating two types of XDP xmit */
> +#define VIRTIO_XDP_TX BIT(0)
> +#define VIRTIO_XDP_REDIR BIT(1)
> +
> /* RX packet size EWMA. The average packet size is used to determine the packet
> * buffer size when refilling RX rings. As the entire RX ring may be refilled
> * at once, the weight is chosen so that the EWMA will be insensitive to short-
> @@ -582,7 +586,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
> struct receive_queue *rq,
> void *buf, void *ctx,
> unsigned int len,
> - bool *xdp_xmit)
> + unsigned int *xdp_xmit)
> {
> struct sk_buff *skb;
> struct bpf_prog *xdp_prog;
> @@ -654,14 +658,14 @@ static struct sk_buff *receive_small(struct net_device *dev,
> trace_xdp_exception(vi->dev, xdp_prog, act);
> goto err_xdp;
> }
> - *xdp_xmit = true;
> + *xdp_xmit |= VIRTIO_XDP_TX;
> rcu_read_unlock();
> goto xdp_xmit;
> case XDP_REDIRECT:
> err = xdp_do_redirect(dev, &xdp, xdp_prog);
> if (err)
> goto err_xdp;
> - *xdp_xmit = true;
> + *xdp_xmit |= VIRTIO_XDP_REDIR;
> rcu_read_unlock();
> goto xdp_xmit;
> default:
> @@ -723,7 +727,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> void *buf,
> void *ctx,
> unsigned int len,
> - bool *xdp_xmit)
> + unsigned int *xdp_xmit)
> {
> struct virtio_net_hdr_mrg_rxbuf *hdr = buf;
> u16 num_buf = virtio16_to_cpu(vi->vdev, hdr->num_buffers);
> @@ -818,7 +822,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> put_page(xdp_page);
> goto err_xdp;
> }
> - *xdp_xmit = true;
> + *xdp_xmit |= VIRTIO_XDP_TX;
> if (unlikely(xdp_page != page))
> put_page(page);
> rcu_read_unlock();
> @@ -830,7 +834,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> put_page(xdp_page);
> goto err_xdp;
> }
> - *xdp_xmit = true;
> + *xdp_xmit |= VIRTIO_XDP_REDIR;
> if (unlikely(xdp_page != page))
> put_page(page);
> rcu_read_unlock();
> @@ -939,7 +943,8 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> }
>
> static int receive_buf(struct virtnet_info *vi, struct receive_queue *rq,
> - void *buf, unsigned int len, void **ctx, bool *xdp_xmit)
> + void *buf, unsigned int len, void **ctx,
> + unsigned int *xdp_xmit)
> {
> struct net_device *dev = vi->dev;
> struct sk_buff *skb;
> @@ -1232,7 +1237,8 @@ static void refill_work(struct work_struct *work)
> }
> }
>
> -static int virtnet_receive(struct receive_queue *rq, int budget, bool *xdp_xmit)
> +static int virtnet_receive(struct receive_queue *rq, int budget,
> + unsigned int *xdp_xmit)
> {
> struct virtnet_info *vi = rq->vq->vdev->priv;
> unsigned int len, received = 0, bytes = 0;
> @@ -1321,7 +1327,7 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
> struct virtnet_info *vi = rq->vq->vdev->priv;
> struct send_queue *sq;
> unsigned int received, qp;
> - bool xdp_xmit = false;
> + unsigned int xdp_xmit = 0;
>
> virtnet_poll_cleantx(rq);
>
> @@ -1331,12 +1337,14 @@ static int virtnet_poll(struct napi_struct *napi, int budget)
> if (received < budget)
> virtqueue_napi_complete(napi, rq->vq, received);
>
> - if (xdp_xmit) {
> + if (xdp_xmit & VIRTIO_XDP_REDIR)
> + xdp_do_flush_map();
> +
> + if (xdp_xmit & VIRTIO_XDP_TX) {
> qp = vi->curr_queue_pairs - vi->xdp_queue_pairs +
> smp_processor_id();
> sq = &vi->sq[qp];
> virtqueue_kick(sq->vq);
> - xdp_do_flush_map();
> }
>
> return received;
>
Acked-by: Jason Wang <jasowang@redhat.com>
Thanks
^ permalink raw reply
* [PATCH net-next v2] net: stmmac: Add support for CBS QDISC
From: Jose Abreu @ 2018-06-27 14:57 UTC (permalink / raw)
To: netdev
Cc: Jose Abreu, David S. Miller, Joao Pinto, Vitor Soares,
Giuseppe Cavallaro, Alexandre Torgue
This adds support for CBS reconfiguration using the TC application.
A new callback was added to TC ops struct and another one to DMA ops to
reconfigure the channel mode.
Tested in GMAC5.10.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Vitor Soares <soares@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
Changes from v1:
- Fixup kbuild warning
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 15 ++++++
drivers/net/ethernet/stmicro/stmmac/hwif.h | 8 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +
drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c | 62 +++++++++++++++++++++++
4 files changed, 87 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index d37f17ca62fe..6e32f8a3710b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -407,6 +407,19 @@ static void dwmac4_enable_tso(void __iomem *ioaddr, bool en, u32 chan)
}
}
+static void dwmac4_qmode(void __iomem *ioaddr, u32 channel, u8 qmode)
+{
+ u32 mtl_tx_op = readl(ioaddr + MTL_CHAN_TX_OP_MODE(channel));
+
+ mtl_tx_op &= ~MTL_OP_MODE_TXQEN_MASK;
+ if (qmode != MTL_QUEUE_AVB)
+ mtl_tx_op |= MTL_OP_MODE_TXQEN;
+ else
+ mtl_tx_op |= MTL_OP_MODE_TXQEN_AV;
+
+ writel(mtl_tx_op, ioaddr + MTL_CHAN_TX_OP_MODE(channel));
+}
+
const struct stmmac_dma_ops dwmac4_dma_ops = {
.reset = dwmac4_dma_reset,
.init = dwmac4_dma_init,
@@ -431,6 +444,7 @@ const struct stmmac_dma_ops dwmac4_dma_ops = {
.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
.enable_tso = dwmac4_enable_tso,
+ .qmode = dwmac4_qmode,
};
const struct stmmac_dma_ops dwmac410_dma_ops = {
@@ -457,4 +471,5 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
.set_rx_tail_ptr = dwmac4_set_rx_tail_ptr,
.set_tx_tail_ptr = dwmac4_set_tx_tail_ptr,
.enable_tso = dwmac4_enable_tso,
+ .qmode = dwmac4_qmode,
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
index e44e7b26ce82..e2a965790648 100644
--- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
+++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
@@ -183,6 +183,7 @@ struct stmmac_dma_ops {
void (*set_rx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
void (*set_tx_tail_ptr)(void __iomem *ioaddr, u32 tail_ptr, u32 chan);
void (*enable_tso)(void __iomem *ioaddr, bool en, u32 chan);
+ void (*qmode)(void __iomem *ioaddr, u32 channel, u8 qmode);
};
#define stmmac_reset(__priv, __args...) \
@@ -235,6 +236,8 @@ struct stmmac_dma_ops {
stmmac_do_void_callback(__priv, dma, set_tx_tail_ptr, __args)
#define stmmac_enable_tso(__priv, __args...) \
stmmac_do_void_callback(__priv, dma, enable_tso, __args)
+#define stmmac_dma_qmode(__priv, __args...) \
+ stmmac_do_void_callback(__priv, dma, qmode, __args)
struct mac_device_info;
struct net_device;
@@ -441,17 +444,22 @@ struct stmmac_mode_ops {
struct stmmac_priv;
struct tc_cls_u32_offload;
+struct tc_cbs_qopt_offload;
struct stmmac_tc_ops {
int (*init)(struct stmmac_priv *priv);
int (*setup_cls_u32)(struct stmmac_priv *priv,
struct tc_cls_u32_offload *cls);
+ int (*setup_cbs)(struct stmmac_priv *priv,
+ struct tc_cbs_qopt_offload *qopt);
};
#define stmmac_tc_init(__priv, __args...) \
stmmac_do_callback(__priv, tc, init, __args)
#define stmmac_tc_setup_cls_u32(__priv, __args...) \
stmmac_do_callback(__priv, tc, setup_cls_u32, __args)
+#define stmmac_tc_setup_cbs(__priv, __args...) \
+ stmmac_do_callback(__priv, tc, setup_cbs, __args)
struct stmmac_regs_off {
u32 ptp_off;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2354e30caa78..93a3bea8576e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3793,6 +3793,8 @@ static int stmmac_setup_tc(struct net_device *ndev, enum tc_setup_type type,
switch (type) {
case TC_SETUP_BLOCK:
return stmmac_setup_tc_block(priv, type_data);
+ case TC_SETUP_QDISC_CBS:
+ return stmmac_tc_setup_cbs(priv, priv, type_data);
default:
return -EOPNOTSUPP;
}
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
index 2258cd8cc844..0b0fca0200b2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_tc.c
@@ -289,7 +289,69 @@ static int tc_init(struct stmmac_priv *priv)
return 0;
}
+static int tc_setup_cbs(struct stmmac_priv *priv,
+ struct tc_cbs_qopt_offload *qopt)
+{
+ u32 tx_queues_count = priv->plat->tx_queues_to_use;
+ u32 queue = qopt->queue;
+ u32 ptr, speed_div;
+ u32 mode_to_use;
+ u64 value;
+ int ret;
+
+ /* Queue 0 is not AVB capable */
+ if (queue <= 0 || queue >= tx_queues_count)
+ return -EINVAL;
+ if (priv->speed != SPEED_100 && priv->speed != SPEED_1000)
+ return -EOPNOTSUPP;
+
+ mode_to_use = priv->plat->tx_queues_cfg[queue].mode_to_use;
+ if (mode_to_use == MTL_QUEUE_DCB && qopt->enable) {
+ ret = stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_AVB);
+ if (ret)
+ return ret;
+
+ priv->plat->tx_queues_cfg[queue].mode_to_use = MTL_QUEUE_AVB;
+ } else if (!qopt->enable) {
+ return stmmac_dma_qmode(priv, priv->ioaddr, queue, MTL_QUEUE_DCB);
+ }
+
+ /* Port Transmit Rate and Speed Divider */
+ ptr = (priv->speed == SPEED_100) ? 4 : 8;
+ speed_div = (priv->speed == SPEED_100) ? 100000 : 1000000;
+
+ /* Final adjustments for HW */
+ value = qopt->idleslope * 1024 * ptr;
+ do_div(value, speed_div);
+ priv->plat->tx_queues_cfg[queue].idle_slope = value & GENMASK(31, 0);
+
+ value = -qopt->sendslope * 1024UL * ptr;
+ do_div(value, speed_div);
+ priv->plat->tx_queues_cfg[queue].send_slope = value & GENMASK(31, 0);
+
+ value = qopt->hicredit * 1024 * 8;
+ priv->plat->tx_queues_cfg[queue].high_credit = value & GENMASK(31, 0);
+
+ value = qopt->locredit * 1024 * 8;
+ priv->plat->tx_queues_cfg[queue].low_credit = value & GENMASK(31, 0);
+
+ ret = stmmac_config_cbs(priv, priv->hw,
+ priv->plat->tx_queues_cfg[queue].send_slope,
+ priv->plat->tx_queues_cfg[queue].idle_slope,
+ priv->plat->tx_queues_cfg[queue].high_credit,
+ priv->plat->tx_queues_cfg[queue].low_credit,
+ queue);
+ if (ret)
+ return ret;
+
+ dev_info(priv->device, "CBS queue %d: send %d, idle %d, hi %d, lo %d\n",
+ queue, qopt->sendslope, qopt->idleslope,
+ qopt->hicredit, qopt->locredit);
+ return 0;
+}
+
const struct stmmac_tc_ops dwmac510_tc_ops = {
.init = tc_init,
.setup_cls_u32 = tc_setup_cls_u32,
+ .setup_cbs = tc_setup_cbs,
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH nf-next v2] openvswitch: use nf_ct_get_tuplepr, invert_tuplepr
From: Pablo Neira Ayuso @ 2018-06-27 15:03 UTC (permalink / raw)
To: Pravin Shelar
Cc: ovs dev, netfilter-devel-u79uwXL29TY76Z2rM5mHXA, Florian Westphal,
Linux Kernel Network Developers
In-Reply-To: <CAOrHB_A_S_+f_weEW-PhNkhKTLXM3NKvAXh82XRTgntMSyNAQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jun 25, 2018 at 08:46:45PM -0700, Pravin Shelar wrote:
> On Mon, Jun 25, 2018 at 8:55 AM, Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org> wrote:
> > These versions deal with the l3proto/l4proto details internally.
> > It removes only caller of nf_ct_get_tuple, so make it static.
> >
> > After this, l3proto->get_l4proto() can be removed in a followup patch.
> >
> > Signed-off-by: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>
> Acked-by: Pravin B Shelar <pshelar-LZ6Gd1LRuIk@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd_reduction
From: Eric Dumazet @ 2018-06-27 15:04 UTC (permalink / raw)
To: Lawrence Brakmo, netdev; +Cc: Kernel Team, Blake Matheny, Alexei Starovoitov
In-Reply-To: <20180627023403.3395818-1-brakmo@fb.com>
On 06/26/2018 07:34 PM, Lawrence Brakmo wrote:
> When using dctcp and doing RPCs, if the last packet of a request is
> ECN marked as having seen congestion (CE), the sender can decrease its
> cwnd to 1. As a result, it will only send one packet when a new request
> is sent. In some instances this results in high tail latencies.
>
> }
> /* Force a fast retransmit upon entering fast recovery */
> sndcnt = max(sndcnt, (tp->prr_out ? 0 : 1));
> - tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
> + tp->snd_cwnd = max((int)tcp_packets_in_flight(tp) + sndcnt, 2);
Canonical way is to use min_t(), please respin (no need to explain this trivia in changelog)
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2] tcp: force cwnd at least 2 in tcp_cwnd_reduction
From: Eric Dumazet @ 2018-06-27 15:06 UTC (permalink / raw)
To: Lawrence Brakmo, netdev; +Cc: Kernel Team, Blake Matheny, Alexei Starovoitov
In-Reply-To: <d07bfdf1-2060-bdaf-8df0-7e33a8f017b7@gmail.com>
On 06/27/2018 08:04 AM, Eric Dumazet wrote:
>
>
> On 06/26/2018 07:34 PM, Lawrence Brakmo wrote:
>> When using dctcp and doing RPCs, if the last packet of a request is
>> ECN marked as having seen congestion (CE), the sender can decrease its
>> cwnd to 1. As a result, it will only send one packet when a new request
>> is sent. In some instances this results in high tail latencies.
>>
>
>> }
>> /* Force a fast retransmit upon entering fast recovery */
>> sndcnt = max(sndcnt, (tp->prr_out ? 0 : 1));
>> - tp->snd_cwnd = tcp_packets_in_flight(tp) + sndcnt;
>> + tp->snd_cwnd = max((int)tcp_packets_in_flight(tp) + sndcnt, 2);
>
> Canonical way is to use min_t(), please respin (no need to explain this trivia in changelog)
Well, max_t() here, obviously :)
^ permalink raw reply
* Re: [PATCH net-next] tcp: replace LINUX_MIB_TCPOFODROP with LINUX_MIB_TCPRMEMFULLDROP for drops due to receive buffer full
From: Yafang Shao @ 2018-06-27 15:14 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Eric Dumazet, David Miller, netdev, LKML
In-Reply-To: <c89b70f9-e70d-35a5-b9a7-7e3ed7d34edf@gmail.com>
On Wed, Jun 27, 2018 at 10:48 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>
> On 06/27/2018 04:50 AM, Yafang Shao wrote:
>> When sk_rmem_alloc is larger than the receive buffer and we can't
>> schedule more memory for it, the skb will be dropped.
>>
>> In above situation, if this skb is put into the ofo queue,
>> LINUX_MIB_TCPOFODROP is incremented to track it,
>> while if this skb is put into the receive queue, there's no record.
>>
>> So LINUX_MIB_TCPOFODROP is replaced with LINUX_MIB_TCPRMEMFULLDROP to track
>> this behavior.
>
>
> Hi Yafang
>
> I do not want to remove TCPOFODrop and mix multiple causes in one single counter.
>
> Please take a look at commit a6df1ae9383697c to have the reasoning.
>
Got it!
What about introduce a new counter, i.e. TCPRcvQFullDrop ?
Thanks
Yafang
^ permalink raw reply
* [PATCH] test_bpf: flag tests that cannot be jited on s390
From: Kleber Sacilotto de Souza @ 2018-06-27 15:19 UTC (permalink / raw)
To: linux-s390, netdev; +Cc: Alexei Starovoitov, Daniel Borkmann
Flag with FLAG_EXPECTED_FAIL the BPF_MAXINSNS tests that cannot be jited
on s390 because they exceed BPF_SIZE_MAX and fail when
CONFIG_BPF_JIT_ALWAYS_ON is set. Also set .expected_errcode to -ENOTSUPP
so the tests pass in that case.
Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
---
lib/test_bpf.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index 60aedc879361..08d3d59dca17 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -5282,21 +5282,31 @@ static struct bpf_test tests[] = {
{ /* Mainly checking JIT here. */
"BPF_MAXINSNS: Ctx heavy transformations",
{ },
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_S390)
+ CLASSIC | FLAG_EXPECTED_FAIL,
+#else
CLASSIC,
+#endif
{ },
{
{ 1, !!(SKB_VLAN_TCI & VLAN_TAG_PRESENT) },
{ 10, !!(SKB_VLAN_TCI & VLAN_TAG_PRESENT) }
},
.fill_helper = bpf_fill_maxinsns6,
+ .expected_errcode = -ENOTSUPP,
},
{ /* Mainly checking JIT here. */
"BPF_MAXINSNS: Call heavy transformations",
{ },
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_S390)
+ CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
+#else
CLASSIC | FLAG_NO_DATA,
+#endif
{ },
{ { 1, 0 }, { 10, 0 } },
.fill_helper = bpf_fill_maxinsns7,
+ .expected_errcode = -ENOTSUPP,
},
{ /* Mainly checking JIT here. */
"BPF_MAXINSNS: Jump heavy test",
@@ -5347,18 +5357,28 @@ static struct bpf_test tests[] = {
{
"BPF_MAXINSNS: exec all MSH",
{ },
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_S390)
+ CLASSIC | FLAG_EXPECTED_FAIL,
+#else
CLASSIC,
+#endif
{ 0xfa, 0xfb, 0xfc, 0xfd, },
{ { 4, 0xababab83 } },
.fill_helper = bpf_fill_maxinsns13,
+ .expected_errcode = -ENOTSUPP,
},
{
"BPF_MAXINSNS: ld_abs+get_processor_id",
{ },
+#if defined(CONFIG_BPF_JIT_ALWAYS_ON) && defined(CONFIG_S390)
+ CLASSIC | FLAG_EXPECTED_FAIL,
+#else
CLASSIC,
+#endif
{ },
{ { 1, 0xbee } },
.fill_helper = bpf_fill_ld_abs_get_processor_id,
+ .expected_errcode = -ENOTSUPP,
},
/*
* LD_IND / LD_ABS on fragmented SKBs
--
2.17.1
^ permalink raw reply related
* [PATCH 0/6] Netfilter fixes for net
From: Pablo Neira Ayuso @ 2018-06-27 15:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
Hi David,
The following patchset contains Netfilter fixes for your net tree:
1) Missing netlink attribute validation in nf_queue, uncovered by KASAN,
from Eric Dumazet.
2) Use pointer to sysctl table, save us 192 bytes of memory per netns.
Also from Eric.
3) Possible use-after-free when removing conntrack helper modules due
to missing synchronize RCU call. From Taehee Yoo.
4) Fix corner case in systcl writes to nf_log that lead to appending
data to uninitialized buffer, from Jann Horn.
5) Jann Horn says we may indefinitely block other users of nf_log_mutex
if a userspace access in proc_dostring() blocked e.g. due to a
userfaultfd.
6) Fix garbage collection race for unconfirmed conntrack entries,
from Florian Westphal.
You can pull these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Thanks.
----------------------------------------------------------------
The following changes since commit 7e85dc8cb35abf16455f1511f0670b57c1a84608:
net_sched: blackhole: tell upper qdisc about dropped packets (2018-06-17 08:42:33 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD
for you to fetch changes up to b36e4523d4d56e2595e28f16f6ccf1cd6a9fc452:
netfilter: nf_conncount: fix garbage collection confirm race (2018-06-26 18:28:57 +0200)
----------------------------------------------------------------
Eric Dumazet (2):
netfilter: nf_queue: augment nfqa_cfg_policy
netfilter: ipv6: nf_defrag: reduce struct net memory waste
Florian Westphal (1):
netfilter: nf_conncount: fix garbage collection confirm race
Gao Feng (1):
netfilter: nf_ct_helper: Fix possible panic after nf_conntrack_helper_unregister
Jann Horn (2):
netfilter: nf_log: fix uninit read in nf_log_proc_dostring
netfilter: nf_log: don't hold nf_log_mutex during user access
include/net/net_namespace.h | 1 +
include/net/netns/ipv6.h | 1 -
net/ipv6/netfilter/nf_conntrack_reasm.c | 6 ++--
net/netfilter/nf_conncount.c | 52 +++++++++++++++++++++++++++++----
net/netfilter/nf_conntrack_helper.c | 5 ++++
net/netfilter/nf_log.c | 13 +++++++--
net/netfilter/nfnetlink_queue.c | 3 ++
7 files changed, 69 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH 1/6] netfilter: nf_queue: augment nfqa_cfg_policy
From: Pablo Neira Ayuso @ 2018-06-27 15:22 UTC (permalink / raw)
To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180627152223.3633-1-pablo@netfilter.org>
From: Eric Dumazet <edumazet@google.com>
Three attributes are currently not verified, thus can trigger KMSAN
warnings such as :
BUG: KMSAN: uninit-value in __arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline]
BUG: KMSAN: uninit-value in __fswab32 include/uapi/linux/swab.h:59 [inline]
BUG: KMSAN: uninit-value in nfqnl_recv_config+0x939/0x17d0 net/netfilter/nfnetlink_queue.c:1268
CPU: 1 PID: 4521 Comm: syz-executor120 Not tainted 4.17.0+ #5
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x188/0x2a0 mm/kmsan/kmsan.c:1117
__msan_warning_32+0x70/0xc0 mm/kmsan/kmsan_instr.c:620
__arch_swab32 arch/x86/include/uapi/asm/swab.h:10 [inline]
__fswab32 include/uapi/linux/swab.h:59 [inline]
nfqnl_recv_config+0x939/0x17d0 net/netfilter/nfnetlink_queue.c:1268
nfnetlink_rcv_msg+0xb2e/0xc80 net/netfilter/nfnetlink.c:212
netlink_rcv_skb+0x37e/0x600 net/netlink/af_netlink.c:2448
nfnetlink_rcv+0x2fe/0x680 net/netfilter/nfnetlink.c:513
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x1680/0x1750 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x104f/0x1350 net/netlink/af_netlink.c:1901
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x43fd59
RSP: 002b:00007ffde0e30d28 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fd59
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 00000000004002c8 R11: 0000000000000213 R12: 0000000000401680
R13: 0000000000401710 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:279 [inline]
kmsan_internal_poison_shadow+0xb8/0x1b0 mm/kmsan/kmsan.c:189
kmsan_kmalloc+0x94/0x100 mm/kmsan/kmsan.c:315
kmsan_slab_alloc+0x10/0x20 mm/kmsan/kmsan.c:322
slab_post_alloc_hook mm/slab.h:446 [inline]
slab_alloc_node mm/slub.c:2753 [inline]
__kmalloc_node_track_caller+0xb35/0x11b0 mm/slub.c:4395
__kmalloc_reserve net/core/skbuff.c:138 [inline]
__alloc_skb+0x2cb/0x9e0 net/core/skbuff.c:206
alloc_skb include/linux/skbuff.h:988 [inline]
netlink_alloc_large_skb net/netlink/af_netlink.c:1182 [inline]
netlink_sendmsg+0x76e/0x1350 net/netlink/af_netlink.c:1876
sock_sendmsg_nosec net/socket.c:629 [inline]
sock_sendmsg net/socket.c:639 [inline]
___sys_sendmsg+0xec8/0x1320 net/socket.c:2117
__sys_sendmsg net/socket.c:2155 [inline]
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x331/0x460 net/socket.c:2162
do_syscall_64+0x15b/0x230 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes: fdb694a01f1f ("netfilter: Add fail-open support")
Fixes: 829e17a1a602 ("[NETFILTER]: nfnetlink_queue: allow changing queue length through netlink")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/netfilter/nfnetlink_queue.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index 4ccd2988f9db..ea4ba551abb2 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -1243,6 +1243,9 @@ static int nfqnl_recv_unsupp(struct net *net, struct sock *ctnl,
static const struct nla_policy nfqa_cfg_policy[NFQA_CFG_MAX+1] = {
[NFQA_CFG_CMD] = { .len = sizeof(struct nfqnl_msg_config_cmd) },
[NFQA_CFG_PARAMS] = { .len = sizeof(struct nfqnl_msg_config_params) },
+ [NFQA_CFG_QUEUE_MAXLEN] = { .type = NLA_U32 },
+ [NFQA_CFG_MASK] = { .type = NLA_U32 },
+ [NFQA_CFG_FLAGS] = { .type = NLA_U32 },
};
static const struct nf_queue_handler nfqh = {
--
2.11.0
^ 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