* Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next
From: Jose Abreu @ 2018-06-14 7:38 UTC (permalink / raw)
To: Dinh Nguyen, netdev
Cc: David Miller, clabbe, Jose.Abreu, Dinh Nguyen, Marek Vasut
In-Reply-To: <CADhT+wewQKmqXDqBj4fk_zhJbQdSSK5LTneJGJ9je3tP2eVMDw@mail.gmail.com>
Hello,
On 13-06-2018 21:46, Dinh Nguyen wrote:
> Hi,
>
> The stmmac ethernet has stopped working in linux-next and linus/master
> branch(v4.17-11782-gbe779f03d563)
>
> It appears that the stmmac ethernet has stopped working after these 2 commits:
>
> 4dbbe8dde848 net: stmmac: Add support for U32 TC filter using Flexible RX Parser
> 5f0456b43140 net: stmmac: Implement logic to automatically select HW Interface
>
> If I move to this commit "565020aaeebf net: stmmac: Disable ACS
> Feature for GMAC >= 4", then the stmmac works again on SoCFPGA.
>
> I was following this thread:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_netdev_msg502858.html&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=fvPkLp2xlWolmIYwoFLmALhxlycg1w0UmxiYdT7qojc&s=aC4a2U3X_siDxSNz3c5OeadhEJWll31yP-oi5nNar94&e=
>
> Was wondering if there was a patch to fix dwmac-sun8i that the socfpga
> platform needs as well?
Probably. I will check and get back to you ASAP.
Thanks and Best Regards,
Jose Miguel Abreu
>
> Thanks,
> Dinh
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stübner @ 2018-06-14 7:54 UTC (permalink / raw)
To: David Wu
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <1528956927-32440-1-git-send-email-david.wu@rock-chips.com>
Hi David,
Am Donnerstag, 14. Juni 2018, 08:15:27 CEST schrieb David Wu:
> Add constants and callback functions for the dwmac on PX30 Soc.
> The base structure is the same, but registers and the bits in
> them are moved slightly, and add the clk_mac_speed for selecting
> mac speed.
>
> Signed-off-by: David Wu <david.wu@rock-chips.com>
[...]
> @@ -1042,6 +1101,10 @@ static int rk_gmac_clk_init(struct
> plat_stmmacenet_data *plat) }
> }
>
> + bsp_priv->clk_mac_speed = devm_clk_get(dev, "clk_mac_speed");
> + if (IS_ERR(bsp_priv->clk_mac_speed))
> + dev_err(dev, "cannot get clock %s\n", "clk_mac_speed");
> +
I don't see that new clock documented in the dt-binding.
Also, which clock from the clock-controller does this connect to?
Thanks
Heiko
^ permalink raw reply
* Request to enable setting the nested network namespace
From: Pamela Mei @ 2018-06-14 8:04 UTC (permalink / raw)
To: netdev
In linux, set up 2 network namespaces, ns1 and ns2. "ip netns list"
can view the 2 network namespaces.
Move one network device from linux root namespace to ns1 then from ns1
to ns2, then delete ns2,
expect that network device can move back to ns1,
but actual result is that eth1 is back to linux root network
namespace. I'm not sure whether it's as expected.
Here is the detail test steps:
1.ip netns add ns1
2.ip netns add ns2
3.ip link set eth1 netns ns1
4.ip netns exec ns1 ip link set eth1 netns ns2
5.ip netns del ns2
Expected result: eth1 will be in ns1
Actual result: eth1 is back in linux root namespace 1
Question: is there any method to realize such scenario to make sure
device can be back to ns1 not linux root network namespace 1?
How about if there's a function to enable nest network namespace e.g.
can set ns1 as the parent namespace of ns2, then device can return to
ns1 when ns2 is gone.
Cheers,
Pamela MEI
^ permalink raw reply
* Re: [PATCH v2 net-next 4/6] net: ethernet: ti: cpsw: add CBS Qdisc offload
From: Ilias Apalodimas @ 2018-06-14 8:09 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: grygorii.strashko, davem, corbet, akpm, netdev, linux-doc,
linux-kernel, linux-omap, vinicius.gomes, henrik,
jesus.sanchez-palencia, p-varis, spatton, francois.ozog, yogeshs,
nsekhar, andrew
In-Reply-To: <20180614073650.29659-5-ivan.khoronzhuk@linaro.org>
On Thu, Jun 14, 2018 at 10:36:48AM +0300, Ivan Khoronzhuk wrote:
> The cpsw has up to 4 FIFOs per port and upper 3 FIFOs can feed rate
> limited queue with shaping. In order to set and enable shaping for
> those 3 FIFOs queues the network device with CBS qdisc attached is
> needed. The CBS configuration is added for dual-emac/single port mode
> only, but potentially can be used in switch mode also, based on
> switchdev for instance.
>
> Despite the FIFO shapers can work w/o cpdma level shapers the base
> usage must be in combine with cpdma level shapers as described in TRM,
> that are set as maximum rates for interface queues with sysfs.
>
> One of the possible configuration with txq shapers and CBS shapers:
>
> Configured with echo RATE >
> /sys/class/net/eth0/queues/tx-0/tx_maxrate
> /---------------------------------------------------
> /
> / cpdma level shapers
> +----+ +----+ +----+ +----+ +----+ +----+ +----+ +----+
> | c7 | | c6 | | c5 | | c4 | | c3 | | c2 | | c1 | | c0 |
> \ / \ / \ / \ / \ / \ / \ / \ /
> \ / \ / \ / \ / \ / \ / \ / \ /
> \/ \/ \/ \/ \/ \/ \/ \/
> +---------|------|------|------|-------------------------------------+
> | +----+ | | +---+ |
> | | +----+ | | |
> | v v v v |
> | +----+ +----+ +----+ +----+ p p+----+ +----+ +----+ +----+ |
> | | | | | | | | | o o| | | | | | | | |
> | | f3 | | f2 | | f1 | | f0 | r CPSW r| f3 | | f2 | | f1 | | f0 | |
> | | | | | | | | | t t| | | | | | | | |
> | \ / \ / \ / \ / 0 1\ / \ / \ / \ / |
> | \ X \ / \ / \ / \ / \ / \ / \ / |
> | \/ \ \/ \/ \/ \/ \/ \/ \/ |
> +-------\------------------------------------------------------------+
> \
> \ FIFO shaper, set with CBS offload added in this patch,
> \ FIFO0 cannot be rate limited
> ------------------------------------------------------
>
> CBS shaper configuration is supposed to be used with root MQPRIO Qdisc
> offload allowing to add sk_prio->tc->txq maps that direct traffic to
> appropriate tx queue and maps L2 priority to FIFO shaper.
>
> The CBS shaper is intended to be used for AVB where L2 priority
> (pcp field) is used to differentiate class of traffic. So additionally
> vlan needs to be created with appropriate egress sk_prio->l2 prio map.
>
> If CBS has several tx queues assigned to it, the sum of their
> bandwidth has not overlap bandwidth set for CBS. It's recomended the
> CBS bandwidth to be a little bit more.
>
> The CBS shaper is configured with CBS qdisc offload interface using tc
> tool from iproute2 packet.
>
> For instance:
>
> $ tc qdisc replace dev eth0 handle 100: parent root mqprio num_tc 3 \
> map 2 2 1 0 2 2 2 2 2 2 2 2 2 2 2 2 queues 1@0 1@1 2@2 hw 1
>
> $ tc -g class show dev eth0
> +---(100:ffe2) mqprio
> | +---(100:3) mqprio
> | +---(100:4) mqprio
> |
> +---(100:ffe1) mqprio
> | +---(100:2) mqprio
> |
> +---(100:ffe0) mqprio
> +---(100:1) mqprio
>
> $ tc qdisc add dev eth0 parent 100:1 cbs locredit -1440 \
> hicredit 60 sendslope -960000 idleslope 40000 offload 1
>
> $ tc qdisc add dev eth0 parent 100:2 cbs locredit -1470 \
> hicredit 62 sendslope -980000 idleslope 20000 offload 1
>
> The above code set CBS shapers for tc0 and tc1, for that txq0 and
> txq1 is used. Pay attention, the real set bandwidth can differ a bit
> due to discreteness of configuration parameters.
>
> Here parameters like locredit, hicredit and sendslope are ignored
> internally and are supposed to be set with assumption that maximum
> frame size for frame - 1500.
>
> It's supposed that interface speed is not changed while reconnection,
> not always is true, so inform user in case speed of interface was
> changed, as it can impact on dependent shapers configuration.
>
> For more examples see Documentation.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> drivers/net/ethernet/ti/cpsw.c | 221 +++++++++++++++++++++++++++++++++
> 1 file changed, 221 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index edd14def98df..3623c2994ddf 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -46,6 +46,8 @@
> #include "cpts.h"
> #include "davinci_cpdma.h"
>
> +#include <net/pkt_sched.h>
> +
> #define CPSW_DEBUG (NETIF_MSG_HW | NETIF_MSG_WOL | \
> NETIF_MSG_DRV | NETIF_MSG_LINK | \
> NETIF_MSG_IFUP | NETIF_MSG_INTR | \
> @@ -154,8 +156,12 @@ do { \
> #define IRQ_NUM 2
> #define CPSW_MAX_QUEUES 8
> #define CPSW_CPDMA_DESCS_POOL_SIZE_DEFAULT 256
> +#define CPSW_FIFO_QUEUE_TYPE_SHIFT 16
> +#define CPSW_FIFO_SHAPE_EN_SHIFT 16
> +#define CPSW_FIFO_RATE_EN_SHIFT 20
> #define CPSW_TC_NUM 4
> #define CPSW_FIFO_SHAPERS_NUM (CPSW_TC_NUM - 1)
> +#define CPSW_PCT_MASK 0x7f
>
> #define CPSW_RX_VLAN_ENCAP_HDR_PRIO_SHIFT 29
> #define CPSW_RX_VLAN_ENCAP_HDR_PRIO_MSK GENMASK(2, 0)
> @@ -457,6 +463,8 @@ struct cpsw_priv {
> bool rx_pause;
> bool tx_pause;
> bool mqprio_hw;
> + int fifo_bw[CPSW_TC_NUM];
> + int shp_cfg_speed;
> u32 emac_port;
> struct cpsw_common *cpsw;
> };
> @@ -1081,6 +1089,38 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
> slave_write(slave, mac_lo(priv->mac_addr), SA_LO);
> }
>
> +static bool cpsw_shp_is_off(struct cpsw_priv *priv)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 shift, mask, val;
> +
> + val = readl_relaxed(&cpsw->regs->ptype);
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + shift = CPSW_FIFO_SHAPE_EN_SHIFT + 3 * slave->slave_num;
> + mask = 7 << shift;
> + val = val & mask;
> +
> + return !val;
> +}
> +
> +static void cpsw_fifo_shp_on(struct cpsw_priv *priv, int fifo, int on)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 shift, mask, val;
> +
> + val = readl_relaxed(&cpsw->regs->ptype);
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + shift = CPSW_FIFO_SHAPE_EN_SHIFT + 3 * slave->slave_num;
> + mask = (1 << --fifo) << shift;
> + val = on ? val | mask : val & ~mask;
> +
> + writel_relaxed(val, &cpsw->regs->ptype);
> +}
> +
> static void _cpsw_adjust_link(struct cpsw_slave *slave,
> struct cpsw_priv *priv, bool *link)
> {
> @@ -1120,6 +1160,12 @@ static void _cpsw_adjust_link(struct cpsw_slave *slave,
> mac_control |= BIT(4);
>
> *link = true;
> +
> + if (priv->shp_cfg_speed &&
> + priv->shp_cfg_speed != slave->phy->speed &&
> + !cpsw_shp_is_off(priv))
> + dev_warn(priv->dev,
> + "Speed was changed, CBS sahper speeds are changed!");
typo here, should be shaper
> } else {
> mac_control = 0;
> /* disable forwarding */
> @@ -1589,6 +1635,178 @@ static int cpsw_tc_to_fifo(int tc, int num_tc)
> return CPSW_FIFO_SHAPERS_NUM - tc;
> }
>
> +static int cpsw_set_fifo_bw(struct cpsw_priv *priv, int fifo, int bw)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + u32 val = 0, send_pct, shift;
> + struct cpsw_slave *slave;
> + int pct = 0, i;
> +
> + if (bw > priv->shp_cfg_speed * 1000)
> + goto err;
> +
> + /* shaping has to stay enabled for highest fifos linearly
> + * and fifo bw no more then interface can allow
> + */
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + send_pct = slave_read(slave, SEND_PERCENT);
> + for (i = CPSW_FIFO_SHAPERS_NUM; i > 0; i--) {
> + if (!bw) {
> + if (i >= fifo || !priv->fifo_bw[i])
> + continue;
> +
> + dev_warn(priv->dev, "Prev FIFO%d is shaped", i);
> + continue;
> + }
> +
> + if (!priv->fifo_bw[i] && i > fifo) {
> + dev_err(priv->dev, "Upper FIFO%d is not shaped", i);
> + return -EINVAL;
> + }
> +
> + shift = (i - 1) * 8;
> + if (i == fifo) {
> + send_pct &= ~(CPSW_PCT_MASK << shift);
> + val = DIV_ROUND_UP(bw, priv->shp_cfg_speed * 10);
> + if (!val)
> + val = 1;
> +
> + send_pct |= val << shift;
> + pct += val;
> + continue;
> + }
> +
> + if (priv->fifo_bw[i])
> + pct += (send_pct >> shift) & CPSW_PCT_MASK;
> + }
> +
> + if (pct >= 100)
> + goto err;
> +
> + slave_write(slave, send_pct, SEND_PERCENT);
> + priv->fifo_bw[fifo] = bw;
> +
> + dev_warn(priv->dev, "set FIFO%d bw = %d\n", fifo,
> + DIV_ROUND_CLOSEST(val * priv->shp_cfg_speed, 100));
> +
> + return 0;
> +err:
> + dev_err(priv->dev, "Bandwidth doesn't fit in tc configuration");
> + return -EINVAL;
> +}
> +
> +static int cpsw_set_fifo_rlimit(struct cpsw_priv *priv, int fifo, int bw)
> +{
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + u32 tx_in_ctl_rg, val;
> + int ret;
> +
> + ret = cpsw_set_fifo_bw(priv, fifo, bw);
> + if (ret)
> + return ret;
> +
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + tx_in_ctl_rg = cpsw->version == CPSW_VERSION_1 ?
> + CPSW1_TX_IN_CTL : CPSW2_TX_IN_CTL;
> +
> + if (!bw)
> + cpsw_fifo_shp_on(priv, fifo, bw);
> +
> + val = slave_read(slave, tx_in_ctl_rg);
> + if (cpsw_shp_is_off(priv)) {
> + /* disable FIFOs rate limited queues */
> + val &= ~(0xf << CPSW_FIFO_RATE_EN_SHIFT);
> +
> + /* set type of FIFO queues to normal priority mode */
> + val &= ~(3 << CPSW_FIFO_QUEUE_TYPE_SHIFT);
> +
> + /* set type of FIFO queues to be rate limited */
> + if (bw)
> + val |= 2 << CPSW_FIFO_QUEUE_TYPE_SHIFT;
> + else
> + priv->shp_cfg_speed = 0;
> + }
> +
> + /* toggle a FIFO rate limited queue */
> + if (bw)
> + val |= BIT(fifo + CPSW_FIFO_RATE_EN_SHIFT);
> + else
> + val &= ~BIT(fifo + CPSW_FIFO_RATE_EN_SHIFT);
> + slave_write(slave, val, tx_in_ctl_rg);
> +
> + /* FIFO transmit shape enable */
> + cpsw_fifo_shp_on(priv, fifo, bw);
> + return 0;
> +}
> +
> +/* Defaults:
> + * class A - prio 3
> + * class B - prio 2
> + * shaping for class A should be set first
> + */
> +static int cpsw_set_cbs(struct net_device *ndev,
> + struct tc_cbs_qopt_offload *qopt)
> +{
> + struct cpsw_priv *priv = netdev_priv(ndev);
> + struct cpsw_common *cpsw = priv->cpsw;
> + struct cpsw_slave *slave;
> + int prev_speed = 0;
> + int tc, ret, fifo;
> + u32 bw = 0;
> +
> + tc = netdev_txq_to_tc(priv->ndev, qopt->queue);
> +
> + /* enable channels in backward order, as highest FIFOs must be rate
> + * limited first and for compliance with CPDMA rate limited channels
> + * that also used in bacward order. FIFO0 cannot be rate limited.
> + */
> + fifo = cpsw_tc_to_fifo(tc, ndev->num_tc);
> + if (!fifo) {
> + dev_err(priv->dev, "Last tc%d can't be rate limited", tc);
> + return -EINVAL;
> + }
> +
> + /* do nothing, it's disabled anyway */
> + if (!qopt->enable && !priv->fifo_bw[fifo])
> + return 0;
> +
> + /* shapers can be set if link speed is known */
> + slave = &cpsw->slaves[cpsw_slave_index(cpsw, priv)];
> + if (slave->phy && slave->phy->link) {
> + if (priv->shp_cfg_speed &&
> + priv->shp_cfg_speed != slave->phy->speed)
> + prev_speed = priv->shp_cfg_speed;
> +
> + priv->shp_cfg_speed = slave->phy->speed;
> + }
> +
> + if (!priv->shp_cfg_speed) {
> + dev_err(priv->dev, "Link speed is not known");
> + return -1;
> + }
> +
> + ret = pm_runtime_get_sync(cpsw->dev);
> + if (ret < 0) {
> + pm_runtime_put_noidle(cpsw->dev);
> + return ret;
> + }
> +
> + bw = qopt->enable ? qopt->idleslope : 0;
> + ret = cpsw_set_fifo_rlimit(priv, fifo, bw);
> + if (ret) {
> + priv->shp_cfg_speed = prev_speed;
> + prev_speed = 0;
> + }
> +
> + if (bw && prev_speed)
> + dev_warn(priv->dev,
> + "Speed was changed, CBS sahper speeds are changed!");
same c/p typo
> +
> + pm_runtime_put_sync(cpsw->dev);
> + return ret;
> +}
> +
> static int cpsw_ndo_open(struct net_device *ndev)
> {
> struct cpsw_priv *priv = netdev_priv(ndev);
> @@ -2263,6 +2481,9 @@ static int cpsw_ndo_setup_tc(struct net_device *ndev, enum tc_setup_type type,
> void *type_data)
> {
> switch (type) {
> + case TC_SETUP_QDISC_CBS:
> + return cpsw_set_cbs(ndev, type_data);
> +
> case TC_SETUP_QDISC_MQPRIO:
> return cpsw_set_mqprio(ndev, type_data);
>
> --
> 2.17.1
>
Other than that looks good
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: David Wu @ 2018-06-14 8:14 UTC (permalink / raw)
To: Heiko Stübner
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <1961033.25ax7s0Z5i@diego>
Hi Heiko,
在 2018年06月14日 15:54, Heiko Stübner 写道:
> I don't see that new clock documented in the dt-binding.
> Also, which clock from the clock-controller does this connect to?
The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
be set rate by the link speed.
^ permalink raw reply
* Re: [BUG] net: stmmac: socfpga ethernet no longer working on linux-next
From: Jose Abreu @ 2018-06-14 8:18 UTC (permalink / raw)
To: Dinh Nguyen, netdev
Cc: David Miller, clabbe, Jose.Abreu, Dinh Nguyen, Marek Vasut
In-Reply-To: <63bfbeb4-ca90-cc8e-3b06-ea257a34a261@synopsys.com>
On 14-06-2018 08:38, Jose Abreu wrote:
> Hello,
>
> On 13-06-2018 21:46, Dinh Nguyen wrote:
>> Hi,
>>
>> The stmmac ethernet has stopped working in linux-next and linus/master
>> branch(v4.17-11782-gbe779f03d563)
>>
>> It appears that the stmmac ethernet has stopped working after these 2 commits:
>>
>> 4dbbe8dde848 net: stmmac: Add support for U32 TC filter using Flexible RX Parser
>> 5f0456b43140 net: stmmac: Implement logic to automatically select HW Interface
>>
>> If I move to this commit "565020aaeebf net: stmmac: Disable ACS
>> Feature for GMAC >= 4", then the stmmac works again on SoCFPGA.
>>
>> I was following this thread:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_netdev_msg502858.html&d=DwIBaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yaVFU4TjGY0gVF8El1uKcisy6TPsyCl9uN7Wsis-qhY&m=fvPkLp2xlWolmIYwoFLmALhxlycg1w0UmxiYdT7qojc&s=aC4a2U3X_siDxSNz3c5OeadhEJWll31yP-oi5nNar94&e=
>>
>> Was wondering if there was a patch to fix dwmac-sun8i that the socfpga
>> platform needs as well?
> Probably. I will check and get back to you ASAP.
This seems to be a different problem. Can you send me your dmesg
log and DT bindings you are using?
>
> Thanks and Best Regards,
> Jose Miguel Abreu
>
>> Thanks,
>> Dinh
^ permalink raw reply
* Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30
From: Heiko Stübner @ 2018-06-14 8:30 UTC (permalink / raw)
To: David Wu
Cc: davem, robh+dt, mark.rutland, huangtao, netdev, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <3aa2445f-ab2a-93b6-3a49-36be6c98d327@rock-chips.com>
Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu:
> Hi Heiko,
>
> 在 2018年06月14日 15:54, Heiko Stübner 写道:
> > I don't see that new clock documented in the dt-binding.
> > Also, which clock from the clock-controller does this connect to?
>
> The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could
> be set rate by the link speed.
Hmm, while these huge number of clocks are somewhat strange,
shouldn't it be named something with _rmii instead of _speed then?
Also, I don't see any clk_enable action for that new clock, so you could
end up with being off?
And someone could convert the driver to use the new clk-bulk APIs [0],
so the large number of clk_prepare_enable calls would be a bit
trimmed down.
Heiko
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-bulk.c
^ permalink raw reply
* Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in xfrm_lookup
From: Kristian Evensen @ 2018-06-14 8:38 UTC (permalink / raw)
To: Steffen Klassert
Cc: Tobias Hommel, Markus Berner, Network Development,
Florian Westphal
In-Reply-To: <CAKfDRXjFC4L7Rmv_-nUbuOLLstvid64JxF9ECOL4Dbzn3FZwLA@mail.gmail.com>
Hello,
On Tue, Jun 12, 2018 at 10:29 AM, Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Thanks for spending time on this. I will see what I can manage in
> terms of a bisect. Our last good kernel was 4.9, so at least it
> narrows the scope down a bit compared to 4.4 or 4.1.
I hope we might have got somewhere. While looking more into ipsec and
4.14, we noticed large performance regressions (-~20%) on some
low-powered devices we are also using. We quickly identified the
removal of the flow cache as the "culprit", and the performance
regression is discussed in the netdev-thread for the removal of the
cache ("xfrm: remove flow cache"). For the time being and in order to
restore the performance, we have reverted the patch series removing
the flow cache. When running our tests (on the APU) after the revert,
we no longer see the crash. Before the revert, the APU would always
crash within some hours. After the revert, our tests have been running
for 24 hours+. Our test is quite basic, we establish 1, 2, 3 ..., 50
tunnels and then run iperf on all tunnels in parallel. The tunnels are
teared down between each iteration.
We are still running the test and will keep doing so, but I thought I
should share this finding in case it can help in fixing the error. I
will report back in case we find out something more, and please let me
know if you have any suggestions for things I can test. I don't for
example know if it is safe to revert one and one commit of the flow
cache, to try to pin the crash even more down.
BR,
Kristian
^ permalink raw reply
* Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled
From: Ilpo Järvinen @ 2018-06-14 8:42 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: Michal Kubecek, netdev, Eric Dumazet, LKML
In-Reply-To: <CAK6E8=eCOLU9AX0+bSrOg_UYBm1mFxrGT=ybksba9B0OUfp7jg@mail.gmail.com>
On Wed, 13 Jun 2018, Yuchung Cheng wrote:
> On Wed, Jun 13, 2018 at 9:55 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> >
> > When F-RTO algorithm (RFC 5682) is used on connection without both SACK and
> > timestamps (either because of (mis)configuration or because the other
> > endpoint does not advertise them), specific pattern loss can make RTO grow
> > exponentially until the sender is only able to send one packet per two
> > minutes (TCP_RTO_MAX).
> >
> > One way to reproduce is to
> >
> > - make sure the connection uses neither SACK nor timestamps
> > - let tp->reorder grow enough so that lost packets are retransmitted
> > after RTO (rather than when high_seq - snd_una > reorder * MSS)
> > - let the data flow stabilize
> > - drop multiple sender packets in "every second" pattern
Hmm? What is deterministically dropping every second packet for a
particular flow that has RTOs in between?
Years back I was privately contacted by somebody from a middlebox vendor
for a case with very similar exponentially growing RTO due to the FRTO
heuristic. It turned out that they didn't want to send dupacks for
out-of-order packets because they wanted to keep the TCP side of their
deep packet inspection middlebox primitive. He claimed that the middlebox
doesn't need to send dupacks because there could be such a TCP
implementation that too doesn't do them either (not that he had anything
to point to besides their middlebox ;-)), which according to him was
not required because of his intepretation of RFC793 (IIRC). ...Nevermind
anything that has occurred since that era.
...Back then, I also envisioned in that mail exchange with him that a
middlebox could break FRTO by always forcing a drop on the key packet
FRTO depends on. Ironically, that is exactly what is required to trigger
this issue? Sure, every a heuristic can be fooled if a deterministic (or
crafted) pattern is introduced to defeat that particular heuristic. ...But
I'd prefer that networks "dropping every second packet" of a flow to be
fixed rather than FRTO?
In addition, one could even argue that the sender is sending whole the
time with lower and lower rate (given the exponentially increasing RTO)
and still gets losses, so that a further rate reduction would be the
correct action. ...But take this intuitive reasoning with some grain of
salt (that is, I can see reasons myself to disagree with it :-)).
> > - either there is no new data to send or acks received in response to new
> > data are also window updates (i.e. not dupacks by definition)
Can you explain what exactly do you mean with this "no new data to send"
condition here as F-RTO is/should not be used if there's no new data to
send?!?
...Or, why is the receiver going against SHOULD in RFC5681:
"A TCP receiver SHOULD send an immediate duplicate ACK when an out-
of-order segment arrives."
? ...And yes, I know there's this very issue with window updates masking
duplicate ACKs in Linux TCP receiver but I was met with some skepticism
on whether fixing it is worth it or not.
> > In this scenario, the sender keeps cycling between retransmitting first
> > lost packet (step 1 of RFC 5682), sending new data by (2b) and timing out
> > again. In this loop, the sender only gets
> >
> > (a) acks for retransmitted segments (possibly together with old ones)
> > (b) window updates
> >
> > Without timestamps, neither can be used for RTT estimator and without SACK,
> > we have no newly sacked segments to estimate RTT either. Therefore each
> > timeout doubles RTO and without usable RTT samples so that there is nothing
> > to counter the exponential growth.
> >
> > While disabling both SACK and timestamps doesn't make any sense, the
> > resulting behaviour is so pathological that it deserves an improvement.
> > (Also, both can be disabled on the other side.) Avoid F-RTO algorithm in
> > case both SACK and timestamps are disabled so that the sender falls back to
> > traditional slow start retransmission.
> >
> > Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
> Acked-by: Yuchung Cheng <ycheng@google.com>
>
> Thanks for the patch (and packedrill test)! I would encourage
> submitting an errata to F-RTO RFC about this case.
Unless there's a convincing explination how such a drop pattern would
occur in real world except due to serious brokeness/misconfiguration on
network side (that should not be there), I'm not that sure it's exactly
what erratas are meant for.
--
i.
^ permalink raw reply
* Re: [RFC PATCH 06/12] xen-blkfront: add callbacks for PM suspend and hibernation
From: Roger Pau Monné @ 2018-06-14 8:43 UTC (permalink / raw)
To: Anchal Agarwal
Cc: tglx, mingo, hpa, x86, boris.ostrovsky, konrad.wilk, netdev,
jgross, xen-devel, linux-kernel, kamatam, eduval, vallish,
fllinden, guruanb, rjw, pavel, len.brown, linux-pm, cyberax
In-Reply-To: <20180613222048.GB33296@kaos-source-ops-60001.pdx1.amazon.com>
Please try to avoid top posting.
On Wed, Jun 13, 2018 at 10:20:48PM +0000, Anchal Agarwal wrote:
> Hi Roger,
> To answer your question, due to the lack of mentioned commit
> (commit 12ea729645ac ("xen/blkback: unmap all persistent grants when
> frontend gets disconnected") in the older dom0 kernels(<3.2),resume from
This fix that you mention is only present in kernels >= 3.18 AFAICT,
and persistent grants where introduced in 3.8 (0a8704a51f38), so
anything < 3.8 should work fine. Not sure why you mention 3.2 here.
> hibernation can fail on guest side. In the absence of the commit,
> Persistant Grants are not unmapped immediately when frontend is
> disconnected from backend and hence leave the block device in an
> inconsistent state. To avoid this unstability and work with larger set
> of kernel versions, this approach had been used. Once you don't have
> any pending req/resp it is safer for guest to resume from hibernation.
I think the fix should be backported (if it hasn't been done yet) to
kernels between 3.8 and 3.18. I don't like to add all this code just
to work around a Linux backend kernel bug.
AFAICT if persistent grants work as expected you could use almost the
same path that's used for migration, greatly reducing the amount of
code that you need to add.
Thanks, Roger.
^ permalink raw reply
* Re: [PATCH bpf v2] xdp: Fix handling of devmap in generic XDP
From: Jesper Dangaard Brouer @ 2018-06-14 8:49 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, brouer
In-Reply-To: <1528942062-2353-1-git-send-email-makita.toshiaki@lab.ntt.co.jp>
On Thu, 14 Jun 2018 11:07:42 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
> the return value type of __devmap_lookup_elem() from struct net_device *
> to struct bpf_dtab_netdev * but forgot to modify generic XDP code
> accordingly.
> Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
> net_device is expected, then skb->dev was set to invalid value.
>
> v2:
> - Fix compiler warning without CONFIG_BPF_SYSCALL.
>
> Fixes: 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue")
> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
Thanks for catching this!
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Notice, that the current code works (and does not crash), but it is
pure luck. Because struct bpf_dtab_netdev happen to have the
net_device as the first member.
struct bpf_dtab_netdev {
struct net_device *dev; /* must be first member, due to tracepoint */
struct bpf_dtab *dtab;
unsigned int bit;
struct xdp_bulk_queue __percpu *bulkq;
struct rcu_head rcu;
};
--
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 bpf v2] xdp: Fix handling of devmap in generic XDP
From: Toshiaki Makita @ 2018-06-14 9:00 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev
In-Reply-To: <20180614104959.4e4e57b8@redhat.com>
On 2018/06/14 17:49, Jesper Dangaard Brouer wrote:
> On Thu, 14 Jun 2018 11:07:42 +0900
> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
>
>> Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
>> the return value type of __devmap_lookup_elem() from struct net_device *
>> to struct bpf_dtab_netdev * but forgot to modify generic XDP code
>> accordingly.
>> Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
>> net_device is expected, then skb->dev was set to invalid value.
>>
>> v2:
>> - Fix compiler warning without CONFIG_BPF_SYSCALL.
>>
>> Fixes: 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue")
>> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
>
> Thanks for catching this!
>
> Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
>
> Notice, that the current code works (and does not crash), but it is
> pure luck. Because struct bpf_dtab_netdev happen to have the
> net_device as the first member.
>
> struct bpf_dtab_netdev {
> struct net_device *dev; /* must be first member, due to tracepoint */
> struct bpf_dtab *dtab;
> unsigned int bit;
> struct xdp_bulk_queue __percpu *bulkq;
> struct rcu_head rcu;
> };
>
Actually no, the current code does not work and can crash, because we
need to dereference the pointer, i.e. need fwd->dev (IOW *fwd) not fwd.
--
Toshiaki Makita
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-queue] i40e: Fix incorrect skb reserved size on rx
From: Malek, Patryk @ 2018-06-14 9:14 UTC (permalink / raw)
To: Toshiaki Makita, Daniel Borkmann, Kirsher, Jeffrey T
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <8963a38e-0583-1a3f-bcfe-8a62d5da6dbf@lab.ntt.co.jp>
> On 2018/06/13 18:06, Daniel Borkmann wrote:
> > On 06/13/2018 10:08 AM, Toshiaki Makita wrote:
> >> i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
> >> xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary
> here
> >> and mac_header/data feilds in skb becomes incorrect, and breaks
Shouldn't this be fields instead of feilds?
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net-queue] i40e: Fix incorrect skb reserved size on rx
From: Toshiaki Makita @ 2018-06-14 9:21 UTC (permalink / raw)
To: Malek, Patryk
Cc: Daniel Borkmann, Kirsher, Jeffrey T,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <FA03331EB45A2544B0CBCB1A14B6429E2B2A3ED7@IRSMSX104.ger.corp.intel.com>
On 2018/06/14 18:14, Malek, Patryk wrote:
>> On 2018/06/13 18:06, Daniel Borkmann wrote:
>>> On 06/13/2018 10:08 AM, Toshiaki Makita wrote:
>>>> i40e_build_skb() reserves I40E_SKB_PAD + (xdp->data -
>>>> xdp->data_hard_start) but obviously I40E_SKB_PAD is unnecessary
>> here
>>>> and mac_header/data feilds in skb becomes incorrect, and breaks
>
> Shouldn't this be fields instead of feilds?
Thanks, but this is now superseded by Daniel's patch so dropped I think.
http://patchwork.ozlabs.org/patch/928778/
--
Toshiaki Makita
^ permalink raw reply
* Re: Request to enable setting the nested network namespace
From: Jiri Pirko @ 2018-06-14 9:27 UTC (permalink / raw)
To: Pamela Mei; +Cc: netdev
In-Reply-To: <CAG89sxLKUdcDNj8JHSX_QnHxJitZEMBpDywUDkZpy9qv8wGanw@mail.gmail.com>
Thu, Jun 14, 2018 at 10:04:57AM CEST, pamela.mei@gmail.com wrote:
>In linux, set up 2 network namespaces, ns1 and ns2. "ip netns list"
>can view the 2 network namespaces.
>Move one network device from linux root namespace to ns1 then from ns1
>to ns2, then delete ns2,
>expect that network device can move back to ns1,
>but actual result is that eth1 is back to linux root network
>namespace. I'm not sure whether it's as expected.
>
>Here is the detail test steps:
>
>1.ip netns add ns1
>
>2.ip netns add ns2
>
>3.ip link set eth1 netns ns1
>
>4.ip netns exec ns1 ip link set eth1 netns ns2
>
>5.ip netns del ns2
>
>Expected result: eth1 will be in ns1
>
>Actual result: eth1 is back in linux root namespace 1
>
>Question: is there any method to realize such scenario to make sure
>device can be back to ns1 not linux root network namespace 1?
>
>How about if there's a function to enable nest network namespace e.g.
>can set ns1 as the parent namespace of ns2, then device can return to
>ns1 when ns2 is gone.
You would have to track the whole history of netns changes for each
netdevice. That does not sound right. Move back to initial netns seems
correct to me.
>
>
>Cheers,
>
>Pamela MEI
^ permalink raw reply
* Re: [PATCH bpf v2] xdp: Fix handling of devmap in generic XDP
From: Jesper Dangaard Brouer @ 2018-06-14 9:33 UTC (permalink / raw)
To: Toshiaki Makita; +Cc: Alexei Starovoitov, Daniel Borkmann, netdev, brouer
In-Reply-To: <23f82d78-88dd-a5e5-ecb1-718fcf5c4a1e@lab.ntt.co.jp>
On Thu, 14 Jun 2018 18:00:22 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/06/14 17:49, Jesper Dangaard Brouer wrote:
> > On Thu, 14 Jun 2018 11:07:42 +0900
> > Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >
> >> Commit 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue") changed
> >> the return value type of __devmap_lookup_elem() from struct net_device *
> >> to struct bpf_dtab_netdev * but forgot to modify generic XDP code
> >> accordingly.
> >> Thus generic XDP incorrectly used struct bpf_dtab_netdev where struct
> >> net_device is expected, then skb->dev was set to invalid value.
> >>
> >> v2:
> >> - Fix compiler warning without CONFIG_BPF_SYSCALL.
> >>
> >> Fixes: 67f29e07e131 ("bpf: devmap introduce dev_map_enqueue")
> >> Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp>
> >
> > Thanks for catching this!
> >
> > Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
> >
> > Notice, that the current code works (and does not crash), but it is
> > pure luck. Because struct bpf_dtab_netdev happen to have the
> > net_device as the first member.
> >
> > struct bpf_dtab_netdev {
> > struct net_device *dev; /* must be first member, due to tracepoint */
> > struct bpf_dtab *dtab;
> > unsigned int bit;
> > struct xdp_bulk_queue __percpu *bulkq;
> > struct rcu_head rcu;
> > };
> >
>
> Actually no, the current code does not work and can crash, because we
> need to dereference the pointer, i.e. need fwd->dev (IOW *fwd) not fwd.
You are right, I ran some more tests, and yes, I managed to crash the
kernel. Strange that is worked in my initial testing. Now it
consistently crash.
[] general protection fault: 0000 [#1] SMP PTI
[] Modules linked in: time_bench_sample(O) time_bench(O) fuse mlx5_ib ib_uverbs ib_core tun nfnetli
nllc bpfilter sunrpc coretemp kvm_intel kvm irqbypass intel_cstate intel_uncore intel_rapl_perf pcs
phpchp wmi ipmi_si ipmi_devintf ipmi_msghandler acpi_pad sch_fq_codel hid_generic mlx5_core i40e ml
xdevlink mdio i2c_algo_bit ptp sd_mod i2c_core pps_core [last unloaded: x_tables]
[] CPU: 0 PID: 8 Comm: ksoftirqd/0 Tainted: G W O 4.17.0-rc7-net-next-xdp-xdp_paper01+
[] Hardware name: Supermicro Super Server/X10SRi-F, BIOS 2.0a 08/01/2016
[] RIP: 0010:netdev_pick_tx+0x3f/0xc0
[] RSP: 0018:ffffc900031c3b98 EFLAGS: 00010296
[] RAX: dead000000000200 RBX: ffff88070f3d2e80 RCX: 0000000000000200
[] RDX: 0000000000000000 RSI: ffff88070b678d00 RDI: ffff88070f3d2e80
[] RBP: ffff88070f3d2e80 R08: ffff88084fda8080 R09: ffff88087c802f00
[] R10: ffffea001c2d1e00 R11: ffff88081e8287f0 R12: ffff88070b678d00
[] R13: ffffc90003843000 R14: 0000000000000000 R15: ffffc900031c3c30
[] FS: 0000000000000000(0000) GS:ffff88087fc00000(0000) knlGS:0000000000000000
[] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[] CR2: 00007fc939b36140 CR3: 000000087f20a005 CR4: 00000000003606f0
[] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[] Call Trace:
[] generic_xdp_tx+0x24/0x180
[] xdp_do_generic_redirect+0x240/0x390
[] do_xdp_generic+0x250/0x3b0
[] ? kmem_cache_alloc+0x38/0x1c0
[] netif_receive_skb_internal+0x8d/0xe0
[] napi_gro_receive+0xb5/0xd0
[] mlx5e_handle_rx_cqe+0x1a4/0x5d0 [mlx5_core]
[] mlx5e_poll_rx_cq+0xbc/0x8d0 [mlx5_core]
[] ? mlx5e_post_rx_wqes+0x2bc/0x400 [mlx5_core]
[] mlx5e_napi_poll+0xb0/0xcc0 [mlx5_core]
[] net_rx_action+0x145/0x3d0
[] ? sort_range+0x20/0x20
[] __do_softirq+0xdc/0x2b4
[] ? sort_range+0x20/0x20
[] run_ksoftirqd+0x18/0x20
[] smpboot_thread_fn+0xdf/0x150
[] kthread+0x111/0x130
[] ? kthread_create_worker_on_cpu+0x70/0x70
[] ret_from_fork+0x1f/0x30
[] Code: 00 83 e8 01 3d ff 1f 00 00 76 10 65 8b 05 3a 02 94 7e 83 c0 01 89 86 ac 00 00 00 83 bd 8c 03 00 00 01 74 52 48 8b 85 e8 01 00 00 <48> 8b 40 30 48 85 c0 74 48 48 c7 c1 50 85 6c 81 4c 89 e6 48 89
[] RIP: netdev_pick_tx+0x3f/0xc0 RSP: ffffc900031c3b98
[] ---[ end trace 8b77c7349af71e1b ]---
[] Kernel panic - not syncing: Fatal exception in interrupt
[] Kernel Offset: disabled
[] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
(gdb) list *(generic_xdp_tx)+0x24
0xffffffff816cf874 is in generic_xdp_tx (net/core/dev.c:4142).
4137 struct netdev_queue *txq;
4138 bool free_skb = true;
4139 int cpu, rc;
4140
4141 txq = netdev_pick_tx(dev, skb, NULL);
4142 cpu = smp_processor_id();
4143 HARD_TX_LOCK(dev, txq, cpu);
4144 if (!netif_xmit_stopped(txq)) {
4145 rc = netdev_start_xmit(skb, dev, txq, 0);
4146 if (dev_xmit_complete(rc))
(gdb) list *(netdev_pick_tx)+0x3f
0xffffffff816ceeef is in netdev_pick_tx (net/core/dev.c:3472).
3467 #endif
3468
3469 if (dev->real_num_tx_queues != 1) {
3470 const struct net_device_ops *ops = dev->netdev_ops;
3471
3472 if (ops->ndo_select_queue)
3473 queue_index = ops->ndo_select_queue(dev, skb, accel_priv,
3474 __netdev_pick_tx);
3475 else
3476 queue_index = __netdev_pick_tx(dev, skb);
(gdb)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled
From: Michal Kubecek @ 2018-06-14 9:34 UTC (permalink / raw)
To: Ilpo Jarvinen; +Cc: Yuchung Cheng, netdev, Eric Dumazet, LKML
In-Reply-To: <alpine.DEB.2.20.1806141045430.29120@whs-18.cs.helsinki.fi>
On Thu, Jun 14, 2018 at 11:42:43AM +0300, Ilpo Järvinen wrote:
> On Wed, 13 Jun 2018, Yuchung Cheng wrote:
>
> > On Wed, Jun 13, 2018 at 9:55 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
> > >
> > > When F-RTO algorithm (RFC 5682) is used on connection without both SACK and
> > > timestamps (either because of (mis)configuration or because the other
> > > endpoint does not advertise them), specific pattern loss can make RTO grow
> > > exponentially until the sender is only able to send one packet per two
> > > minutes (TCP_RTO_MAX).
> > >
> > > One way to reproduce is to
> > >
> > > - make sure the connection uses neither SACK nor timestamps
> > > - let tp->reorder grow enough so that lost packets are retransmitted
> > > after RTO (rather than when high_seq - snd_una > reorder * MSS)
> > > - let the data flow stabilize
> > > - drop multiple sender packets in "every second" pattern
>
> Hmm? What is deterministically dropping every second packet for a
> particular flow that has RTOs in between?
AFAIK the customer we managed to push to investigate the primary source
of the packet loss identified some problems with their load balancing
solution but I don't have more details. For the record, the loss didn't
last through the phase of RTO growing exponentially (so that there were
no lost retransmissions) but did last long enough to drop at least 20
packets. With the exponential growth, that was enough for RTO to reach
TCP_RTO_MAX (120s) and make the connection essentially stalled.
Actually, it doesn't need to be exactly "every second". As long as you
don't lose two consecutive segments (which would allow you to fall back
in step (2a)), you can have more than one received segments between them
and get the same issue.
> Years back I was privately contacted by somebody from a middlebox vendor
> for a case with very similar exponentially growing RTO due to the FRTO
> heuristic. It turned out that they didn't want to send dupacks for
> out-of-order packets because they wanted to keep the TCP side of their
> deep packet inspection middlebox primitive. He claimed that the middlebox
> doesn't need to send dupacks because there could be such a TCP
> implementation that too doesn't do them either (not that he had anything
> to point to besides their middlebox ;-)), which according to him was
> not required because of his intepretation of RFC793 (IIRC). ...Nevermind
> anything that has occurred since that era.
>
> ...Back then, I also envisioned in that mail exchange with him that a
> middlebox could break FRTO by always forcing a drop on the key packet
> FRTO depends on. Ironically, that is exactly what is required to trigger
> this issue? Sure, every a heuristic can be fooled if a deterministic (or
> crafted) pattern is introduced to defeat that particular heuristic.
OK, let me elaborate a bit more about the background. Within last few
months, we had six different reports of TCP stalls (typically for NFS
connections alternating between idle period and bulk transfers) which
started after an upgrade from SLE11 (with 3.0 kernel) to SLE12 SP2 or
SP3 (both 4.4 kernel).
Two of them were analysed down to the NAS on the other side which was
sending SACK blocks violating the RFC in two different ways - as
described in thread "TCP one-by-one acking - RFC interpretation
question".
Three of them do not seem to show any apparent RFC violation and the
problem is only in RTO doubling with each retransmission while there are
no usable replies that could be used for RTT estimate (in the absence of
both SACK and timestamps).
For the sake of completeness, there was also one report from two days
ago which looked almost the same but in the end it turned out that in
this case, SLES (with Firefox) was the receiver and sender was actually
Windows 2016 server with Microsoft IIS.
> I'd prefer that networks "dropping every second packet" of a flow to be
> fixed rather than FRTO?
Yes, that was my first reaction that their primary focus should be the
lossy network. However, it's not behaving like this all the time, the
periods of loss are relatively short - but long enough to trigger the
"RTO loop".
> In addition, one could even argue that the sender is sending whole the
> time with lower and lower rate (given the exponentially increasing RTO)
> and still gets losses, so that a further rate reduction would be the
> correct action. ...But take this intuitive reasoning with some grain of
> salt (that is, I can see reasons myself to disagree with it :-)).
As I explained above, the loss was over by the time of first RTO
retransmission. I should probably have made that clear in the commit
message.
> > > - either there is no new data to send or acks received in response to new
> > > data are also window updates (i.e. not dupacks by definition)
>
> Can you explain what exactly do you mean with this "no new data to send"
> condition here as F-RTO is/should not be used if there's no new data to
> send?!?
AFAICS RFC 5682 is not explicit about this and offers multiple options.
Anyway, this is not essential and in most of the customer provided
captures, it wasn't the case.
> ...Or, why is the receiver going against SHOULD in RFC5681:
> "A TCP receiver SHOULD send an immediate duplicate ACK when an out-
> of-order segment arrives."
> ? ...And yes, I know there's this very issue with window updates masking
> duplicate ACKs in Linux TCP receiver but I was met with some skepticism
> on whether fixing it is worth it or not.
Normally, we would have timestamps (and even SACK). Without them, you
cannot reliably recognize a dupack with changed window size from
a spontaneous window update.
> > Acked-by: Yuchung Cheng <ycheng@google.com>
> >
> > Thanks for the patch (and packedrill test)! I would encourage
> > submitting an errata to F-RTO RFC about this case.
>
> Unless there's a convincing explination how such a drop pattern would
> occur in real world except due to serious brokeness/misconfiguration on
> network side (that should not be there), I'm not that sure it's exactly
> what erratas are meant for.
As explained above, this commit was not inspired by some theoretical
study trying to find dark corner cases, it was result of investigation
of reports from multiple customer encountering the problem in
real-life. Sure, there was always something bad, namely SACK/timestamps
being disabled and network losing packets, but the effect (one packet
per two minutes) is so disastrous that I believe it should be handled.
Michal Kubecek
^ permalink raw reply
* Re: WARNING in bpf_prog_select_runtime
From: Daniel Borkmann @ 2018-06-14 9:45 UTC (permalink / raw)
To: syzbot, ast, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000556929056e952ae0@google.com>
On 06/14/2018 09:37 AM, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: ee946c36be21 Merge tag 'platform-drivers-x86-v4.17-2' of g..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11ca275b800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=889265cebaf9bda1
> dashboard link: https://syzkaller.appspot.com/bug?extid=3b889862e65a98317058
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17530b5b800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+3b889862e65a98317058@syzkaller.appspotmail.com
Will submit a fix for this today.
^ permalink raw reply
* Re: [virtio-dev] Re: [Qemu-devel] [PATCH] qemu: Introduce VIRTIO_NET_F_STANDBY feature bit to virtio_net
From: Cornelia Huck @ 2018-06-14 10:02 UTC (permalink / raw)
To: Siwei Liu
Cc: Samudrala, Sridhar, Alexander Duyck, virtio-dev, aaron.f.brown,
Jiri Pirko, Michael S. Tsirkin, Jakub Kicinski, Netdev,
qemu-devel, virtualization
In-Reply-To: <CADGSJ213f8tJpNXuOhv8qRew-Y5VZAwA+srNMrLZYnKdVGLdAA@mail.gmail.com>
I've been pointed to this discussion (which I had missed previously)
and I'm getting a headache. Let me first summarize how I understand how
this feature is supposed to work, then I'll respond to some individual
points.
The basic idea is to enable guests to migrate seamlessly, while still
making it possible for them to use a passed-through device for more
performance etc. The means to do so is to hook a virtio-net device
together with a network device passed through via vfio. The
vfio-handled device is there for performance, the virtio device for
migratability. We have a new virtio feature bit for that which needs to
be negotiated for that 'combined' device to be available. We have to
consider two cases:
- Older guests that do not support the new feature bit. We presume that
those guests will be confused if they get two network devices with
the same MAC, so the idea is to not show them the vfio-handled device
at all.
- Guests that negotiate the feature bit. We only know positively that
they (a) know the feature bit and (b) are prepared to handle the
consequences of negotiating it after they set the FEATURES_OK bit.
This is therefore the earliest point in time that the vfio-handled
device should be visible or usable for the guest.
On Wed, 13 Jun 2018 18:02:01 -0700
Siwei Liu <loseweigh@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 5:08 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
> > On 6/12/2018 4:34 AM, Michael S. Tsirkin wrote:
> >>
> >> On Mon, Jun 11, 2018 at 10:02:45PM -0700, Samudrala, Sridhar wrote:
> >>>
> >>> On 6/11/2018 7:17 PM, Michael S. Tsirkin wrote:
> >>>>
> >>>> On Tue, Jun 12, 2018 at 09:54:44AM +0800, Jason Wang wrote:
> >>>>>
> >>>>> On 2018年06月12日 01:26, Michael S. Tsirkin wrote:
> >>>>>>
> >>>>>> On Mon, May 07, 2018 at 04:09:54PM -0700, Sridhar Samudrala wrote:
> >>>>>>>
> >>>>>>> This feature bit can be used by hypervisor to indicate virtio_net
> >>>>>>> device to
> >>>>>>> act as a standby for another device with the same MAC address.
> >>>>>>>
> >>>>>>> I tested this with a small change to the patch to mark the STANDBY
> >>>>>>> feature 'true'
> >>>>>>> by default as i am using libvirt to start the VMs.
> >>>>>>> Is there a way to pass the newly added feature bit 'standby' to qemu
> >>>>>>> via libvirt
> >>>>>>> XML file?
> >>>>>>>
> >>>>>>> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> >>>>>>
> >>>>>> So I do not think we can commit to this interface: we
> >>>>>> really need to control visibility of the primary device.
> >>>>>
> >>>>> The problem is legacy guest won't use primary device at all if we do
> >>>>> this.
> >>>>
> >>>> And that's by design - I think it's the only way to ensure the
> >>>> legacy guest isn't confused.
> >>>
> >>> Yes. I think so. But i am not sure if Qemu is the right place to control
> >>> the visibility
> >>> of the primary device. The primary device may not be specified as an
> >>> argument to Qemu. It
> >>> may be plugged in later.
> >>> The cloud service provider is providing a feature that enables low
> >>> latency datapath and live
> >>> migration capability.
> >>> A tenant can use this feature only if he is running a VM that has
> >>> virtio-net with failover support.
So, do you know from the outset that there will be such a coupled
device? I.e., is it a property of the VM definition?
Can there be a 'prepared' virtio-net device that presents the STANDBY
feature even if there currently is no vfio-handled device available --
but making it possible to simply hotplug that device later?
Should it be possible to add a virtio/vfio pair later on?
> >>
> >> Well live migration is there already. The new feature is low latency
> >> data path.
> >
> >
> > we get live migration with just virtio. But I meant live migration with VF
> > as
> > primary device.
> >
> >>
> >> And it's the guest that needs failover support not the VM.
> >
> >
> > Isn't guest and VM synonymous?
I think we need to be really careful to not mix up the two: The VM
contains the definitions, but it is up to the guest how it uses them.
> >
> >
> >>
> >>
> >>> I think Qemu should check if guest virtio-net supports this feature and
> >>> provide a mechanism for
> >>> an upper layer indicating if the STANDBY feature is successfully
> >>> negotiated or not.
> >>> The upper layer can then decide if it should hot plug a VF with the same
> >>> MAC and manage the 2 links.
> >>> If VF is successfully hot plugged, virtio-net link should be disabled.
> >>
> >> Did you even talk to upper layer management about it?
> >> Just list the steps they need to do and you will see
> >> that's a lot of machinery to manage by the upper layer.
> >>
> >> What do we gain in flexibility? As far as I can see the
> >> only gain is some resources saved for legacy VMs.
> >>
> >> That's not a lot as tenant of the upper layer probably already has
> >> at least a hunch that it's a new guest otherwise
> >> why bother specifying the feature at all - you
> >> save even more resources without it.
> >>
> >
> > I am not all that familiar with how Qemu manages network devices. If we can
> > do all the
> > required management of the primary/standby devices within Qemu, that is
> > definitely a better
> > approach without upper layer involvement.
>
> Right. I would imagine in the extreme case the upper layer doesn't
> have to be involved at all if QEMU manages all hot plug/unplug logic.
> The management tool can supply passthrough device and virtio with the
> same group UUID, QEMU auto-manages the presence of the primary, and
> hot plug the device as needed before or after the migration.
I do not really see how you can manage that kind of stuff in QEMU only.
Have you talked to some libvirt folks? (And I'm not sure what you refer
to with 'group UUID'?)
Also, I think you need to make a distinction between hotplugging a
device and making it visible to the guest. What does 'hotplugging' mean
here? Adding it to the VM definition? Would it be enough to have the
vfio-based device not operational until the virtio feature bit has been
negotiated?
What happens if the guest does not use the vfio-based device after it
has been made available? Will you still disable the virtio-net link?
(All that link handling definitely sounds like a task for libvirt or
the like.)
Regarding hot(un)plugging during migration, I think you also need to
keep in mind that different architectures/busses have different
semantics there. Something that works if there's an unplug handshake may
not work on a platform with surprise removal.
Have you considered guest agents? All of this is punching through
several layers, and I'm not sure if that is a good idea.
^ permalink raw reply
* [PATCH v2 3/5] batman: use BIT_ULL for NL80211_STA_INFO_* attribute types
From: Omer Efrat @ 2018-06-14 10:12 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r, Omer Efrat
Since 'filled' member in station_info changed to u64, BIT_ULL macro
should be used with NL80211_STA_INFO_* attribute types instead of BIT.
The BIT macro uses unsigned long type which some architectures handle as 32bit
and this results in compilation warnings such as:
net/mac80211/sta_info.c:2223:2: warning: left shift count >= width of type
sinfo->filled |= BIT(NL80211_STA_INFO_TID_STATS);
^
Signed-off-by: Omer Efrat <omer.efrat-CtGflUZwD1xBDgjK7y7TUQ@public.gmane.org>
---
net/batman-adv/bat_v_elp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c
index 71c20c1..71e6474 100644
--- a/net/batman-adv/bat_v_elp.c
+++ b/net/batman-adv/bat_v_elp.c
@@ -114,7 +114,7 @@ static u32 batadv_v_elp_get_throughput(struct batadv_hardif_neigh_node *neigh)
}
if (ret)
goto default_throughput;
- if (!(sinfo.filled & BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT)))
+ if (!(sinfo.filled & BIT_ULL(NL80211_STA_INFO_EXPECTED_THROUGHPUT)))
goto default_throughput;
return sinfo.expected_throughput / 100;
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH RESEND] tcp: avoid F-RTO if SACK and timestamps are disabled
From: Ilpo Järvinen @ 2018-06-14 10:18 UTC (permalink / raw)
To: Michal Kubecek; +Cc: Netdev, Eric Dumazet, Yuchung Cheng, LKML
In-Reply-To: <20180613165716.4fy7ufk7jnk3r67r@unicorn.suse.cz>
On Wed, 13 Jun 2018, Michal Kubecek wrote:
> On Wed, Jun 13, 2018 at 06:55:43PM +0200, Michal Kubecek wrote:
> > When F-RTO algorithm (RFC 5682) is used on connection without both SACK and
> > timestamps (either because of (mis)configuration or because the other
> > endpoint does not advertise them), specific pattern loss can make RTO grow
> > exponentially until the sender is only able to send one packet per two
> > minutes (TCP_RTO_MAX).
> >
> > One way to reproduce is to
> >
> > - make sure the connection uses neither SACK nor timestamps
> > - let tp->reorder grow enough so that lost packets are retransmitted
> > after RTO (rather than when high_seq - snd_una > reorder * MSS)
> > - let the data flow stabilize
> > - drop multiple sender packets in "every second" pattern
> > - either there is no new data to send or acks received in response to new
> > data are also window updates (i.e. not dupacks by definition)
> >
> > In this scenario, the sender keeps cycling between retransmitting first
> > lost packet (step 1 of RFC 5682), sending new data by (2b) and timing out
> > again. In this loop, the sender only gets
> >
> > (a) acks for retransmitted segments (possibly together with old ones)
> > (b) window updates
> >
> > Without timestamps, neither can be used for RTT estimator and without SACK,
> > we have no newly sacked segments to estimate RTT either. Therefore each
> > timeout doubles RTO and without usable RTT samples so that there is nothing
> > to counter the exponential growth.
> >
> > While disabling both SACK and timestamps doesn't make any sense, the
> > resulting behaviour is so pathological that it deserves an improvement.
> > (Also, both can be disabled on the other side.) Avoid F-RTO algorithm in
> > case both SACK and timestamps are disabled so that the sender falls back to
> > traditional slow start retransmission.
> >
> > Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>
> I was able to illustrate the issue using a packetdrill script. It cheats
> a bit by setting net.ipv4.tcp_reordering to 30 so that it we can get to
> the issue more quickly. In this case, we don't have more data to send
> but it's not essential; the issue can be reproduced even with sending of
> new data in F-RTO, it would only make everything more complicated.
>
> I was able to run the same script on kernels 4.17-rc6, 4.12 (SLE15) and
> 4.4 (SLE12-SP2). Kernel 3.12 required minor modifications but not in the
> important part (the slow start is a bit slower there).
>
> ---------------------------------------------------------------------------
> --tolerance_usecs=10000
>
> // flush cached TCP metrics
> 0.000 `ip tcp_metrics flush all`
> +0.000 `sysctl -q net.ipv4.tcp_reordering=20`
>
>
> // establish a connection
> +0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> +0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> +0.000 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [131072], 4) = 0
> +0.000 bind(3, ..., ...) = 0
> +0.000 listen(3, 1) = 0
>
> +0.100 < S 0:0(0) win 40000 <mss 1000>
> +0.000 > S. 0:0(0) ack 1 <mss 1460>
> +0.100 < . 1:1(0) ack 1 win 40000
> +0.000 accept(3, ..., ...) = 4
>
> // Send 10 data segments.
> +0.100 write(4, ..., 30000) = 30000
> // For some reason (unknown yet), GSO packets are only 2000 bytes long
> +0.000 > . 1:2001(2000) ack 1
> +0.000 > . 2001:4001(2000) ack 1
> +0.000 > . 4001:6001(2000) ack 1
> +0.000 > . 6001:8001(2000) ack 1
> +0.000 > . 8001:10001(2000) ack 1
> +0.100 < . 1:1(0) ack 2001 win 38000
> +0.000 > . 10001:12001(2000) ack 1
> +0.000 > . 12001:14001(2000) ack 1
> +0.001 < . 1:1(0) ack 4001 win 36000
> +0.000 > . 14001:16001(2000) ack 1
> +0.000 > . 16001:18001(2000) ack 1
> +0.001 < . 1:1(0) ack 6001 win 34000
> +0.000 > . 18001:20001(2000) ack 1
> +0.000 > . 20001:22001(2000) ack 1
> +0.001 < . 1:1(0) ack 8001 win 32000
> +0.000 > . 22001:24001(2000) ack 1
> +0.000 > . 24001:26001(2000) ack 1
> +0.001 < . 1:1(0) ack 10001 win 30000
> +0.000 > . 26001:28001(2000) ack 1
> +0.000 > P. 28001:30001(2000) ack 1
>
> // loss of 12001:13001, 14001:15001, ..., 28001:29001
> +0.100 < . 1:1(0) ack 12001 win 30000 // original ack
> +0.000 < . 1:1(0) ack 12001 win 30000 // 13001:14001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 15001:16001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 17001:18001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 19001:20001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 21001:22001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 13001:24001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 25001:26001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 27001:28001
> +0.000 < . 1:1(0) ack 12001 win 30000 // 29001:30001
>
> // RTO 300ms
> +0.270~+0.330 > . 12001:13001(1000) ack 1
Lets analyze this case:
ca_state = CA_Loss
> +0.100 < . 1:1(0) ack 14001 win 38000
snd_una advances => icsk_retransmits = 0
...The lack of new data segments here seems very relevant to me and it
hides from you what is really happening under the hood...
> // RTO 600ms
> +0.540~+0.660 > . 14001:15001(1000) ack 1
The above should already result false for FRTO in this case:
(new_recovery || icsk->icsk_retransmits) &&
...But it doesn't. If there would be the new data segment they would show
to you that we're running a FRTO bogus undo here (with a burst of new
data segments before the second RTO). The bogus undo on that ACK causes
ca_state to switch away from CA_Loss and FRTO can then reoccur even though
it was not intended. Please, try with this patch:
https://patchwork.ozlabs.org/patch/883654/
...Since you're dealing with non-SACK flows here, you might want to
consider the other fixes in that same series too as they all fix bad
brokeness. I should do an updated version for that series but I've been
waiting for the TCP testsuite to be published...
--
i.
^ permalink raw reply
* Re: [PATCH v2 3/5] batman: use BIT_ULL for NL80211_STA_INFO_* attribute types
From: Sven Eckelmann @ 2018-06-14 10:40 UTC (permalink / raw)
To: Omer Efrat
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1528971137-432-1-git-send-email-omer.efrat-CtGflUZwD1xBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
On Donnerstag, 14. Juni 2018 13:12:17 CEST Omer Efrat wrote:
> Since 'filled' member in station_info changed to u64, BIT_ULL macro
> should be used with NL80211_STA_INFO_* attribute types instead of BIT.
>
> The BIT macro uses unsigned long type which some architectures handle as 32bit
> and this results in compilation warnings such as:
>
> net/mac80211/sta_info.c:2223:2: warning: left shift count >= width of type
> sinfo->filled |= BIT(NL80211_STA_INFO_TID_STATS);
> ^
>
> Signed-off-by: Omer Efrat <omer.efrat-CtGflUZwD1xBDgjK7y7TUQ@public.gmane.org>
> ---
> net/batman-adv/bat_v_elp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
It is called "batman-adv" and not "batman". And when (as in commit) did it
change to 64 bit? Shouldn't there be a "Fixed: " line to know which kernels
are affected (especially for the stable kernel developers).
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/5] batman: use BIT_ULL for NL80211_STA_INFO_* attribute types
From: Sven Eckelmann @ 2018-06-14 10:53 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Omer Efrat
In-Reply-To: <32533954.9n15W0HXMB@bentobox>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Hi,
here are the infos which were missing and which should be included in the
commit message
> > Since 'filled' member in station_info changed to u64
in commit 739960f128e5 ("cfg80211/nl80211: Add support for
NL80211_STA_INFO_RX_DURATION")
[...]
Fixes: d62890885efb ("batman-adv: Accept only filled wifi station info")
> > Signed-off-by: Omer Efrat <omer.efrat-CtGflUZwD1xBDgjK7y7TUQ@public.gmane.org>
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH v2 3/5] batman: use BIT_ULL for NL80211_STA_INFO_* attribute types
From: Johannes Berg @ 2018-06-14 11:05 UTC (permalink / raw)
To: Sven Eckelmann, b.a.t.m.a.n; +Cc: Omer Efrat, netdev, linux-wireless
In-Reply-To: <1567584.jbsRn7ofiA@bentobox>
On Thu, 2018-06-14 at 12:53 +0200, Sven Eckelmann wrote:
> Hi,
>
> here are the infos which were missing and which should be included in the
> commit message
>
> > > Since 'filled' member in station_info changed to u64
>
> in commit 739960f128e5 ("cfg80211/nl80211: Add support for
> NL80211_STA_INFO_RX_DURATION")
Yeah, which actually means this patch isn't needed?
BIT(NL80211_STA_INFO_EXPECTED_THROUGHPUT) is fine since
NL80211_STA_INFO_EXPECTED_THROUGHPUT is actually == 27.
johannes
^ permalink raw reply
* Re: [PATCH] selftests: bpf: config: add config fragments
From: William Tu @ 2018-06-14 11:06 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Anders Roxell, Alexei Starovoitov, Shuah Khan,
Linux Kernel Network Developers, LKML, linux-kselftest
In-Reply-To: <d6851756-ae3b-09ec-f487-1eeece6bd4c6@iogearbox.net>
On Tue, Jun 12, 2018 at 5:08 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 06/12/2018 01:05 PM, Anders Roxell wrote:
>> Tests test_tunnel.sh fails due to config fragments ins't enabled.
>>
>> Fixes: 933a741e3b82 ("selftests/bpf: bpf tunnel test.")
>> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
>> ---
>>
>> All tests passes except ip6gretap that still fails. I'm unsure why.
>> Ideas?
Hi Anders,
ip6erspan is based on ip6gretap, does ip6erspan pass?
Regards,
William
^ 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