* Re: [PATCH bpf] bpf: fix BPF_ALU32 | BPF_ARSH on BE arches
From: Song Liu @ 2019-06-25 20:15 UTC (permalink / raw)
To: Jiong Wang
Cc: Alexei Starovoitov, Daniel Borkmann, yauheni.kaliuta, bpf,
Networking, oss-drivers
In-Reply-To: <1561480910-23543-1-git-send-email-jiong.wang@netronome.com>
On Tue, Jun 25, 2019 at 12:31 PM Jiong Wang <jiong.wang@netronome.com> wrote:
>
> Yauheni reported the following code do not work correctly on BE arches:
>
> ALU_ARSH_X:
> DST = (u64) (u32) ((*(s32 *) &DST) >> SRC);
> CONT;
> ALU_ARSH_K:
> DST = (u64) (u32) ((*(s32 *) &DST) >> IMM);
> CONT;
>
> and are causing failure of test_verifier test 'arsh32 on imm 2' on BE
> arches.
>
> The code is taking address and interpreting memory directly, so is not
> endianness neutral. We should instead perform standard C type casting on
> the variable. A u64 to s32 conversion will drop the high 32-bit and reserve
> the low 32-bit as signed integer, this is all we want.
>
> Fixes: 2dc6b100f928 ("bpf: interpreter support BPF_ALU | BPF_ARSH")
> Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
> Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
> Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Acked-by: Song Liu <songliubraving@fb.com>
I guess we need:
Cc: <stable@vger.kernel.org> #v5.0+
> ---
> kernel/bpf/core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 080e2bb..f2148db 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1364,10 +1364,10 @@ static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack)
> insn++;
> CONT;
> ALU_ARSH_X:
> - DST = (u64) (u32) ((*(s32 *) &DST) >> SRC);
> + DST = (u64) (u32) (((s32) DST) >> SRC);
> CONT;
> ALU_ARSH_K:
> - DST = (u64) (u32) ((*(s32 *) &DST) >> IMM);
> + DST = (u64) (u32) (((s32) DST) >> IMM);
> CONT;
> ALU64_ARSH_X:
> (*(s64 *) &DST) >>= SRC;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
From: David Ahern @ 2019-06-25 20:22 UTC (permalink / raw)
To: Stephen Suryaputra, netdev
In-Reply-To: <20190625103359.31102-1-ssuryaextr@gmail.com>
On 6/25/19 4:33 AM, Stephen Suryaputra wrote:
> @@ -363,10 +376,20 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> #endif
> ) {
> struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
> - if (newskb)
> + if (newskb) {
> + /* Reset rt_iif so that inet_iif() will return
> + * skb->dev->ifIndex which is the VRF device for
> + * socket lookup. Setting this to VRF ifindex
> + * causes ipi_ifindex in in_pktinfo to be
> + * overwritten, see ipv4_pktinfo_prepare().
> + */
> + if (netif_is_l3_slave(dev))
seems like the rt_iif is a problem for recirculated mcast packets in
general, not just ones tied to a VRF.
> + ip_mc_reset_rt_iif(net, rt, newskb);
> +
> NF_HOOK(NFPROTO_IPV4, NF_INET_POST_ROUTING,
> net, sk, newskb, NULL, newskb->dev,
> ip_mc_finish_output);
> + }
> }
>
> /* Multicasts with ttl 0 must not go beyond the host */
^ permalink raw reply
* Re: [PATCH rdma-next v1 11/12] IB/mlx5: Implement DEVX dispatching event
From: Jason Gunthorpe @ 2019-06-25 20:23 UTC (permalink / raw)
To: Yishai Hadas
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <a2380ea6-4542-c72c-96f7-e68786847ccc@dev.mellanox.co.il>
On Tue, Jun 25, 2019 at 05:41:49PM +0300, Yishai Hadas wrote:
> > > > Why don't we return EIO as soon as is-destroyed happens? What is the
> > > > point of flushing out the accumulated events?
> > >
> > > It follows the above uverb code/logic that returns existing events even in
> > > that case, also the async command events in this file follows that logic, I
> > > suggest to stay consistent.
> >
> > Don't follow broken uverbs stuff...
>
> May it be that there is some event that we still want to deliver post
> unbind/hot-unplug ? for example IB_EVENT_DEVICE_FATAL in uverbs and others
> from the driver code.
EIO is DEVICE_FATAL.
> Not sure that we want to change this logic.
> What do you think ?
I think this code should exit immediately with EIO if the device is
disassociated.
> > > > Maybe the event should be re-added on error? Tricky.
> > >
> > > What will happen if another copy_to_user may then fail again (loop ?) ...
> > > not sure that we want to get into this tricky handling ...
> > >
> > > As of above, It follows the logic from uverbs at that area.
> > > https://elixir.bootlin.com/linux/latest/source/drivers/infiniband/core/uverbs_main.c#L267
> >
> > again it is wrong...
> >
> > There is no loop if you just stick the item back on the head of the
> > list and exit, which is probably the right thing to do..
> >
>
> What if copy_to_user() will fail again just later on ? we might end-up with
> loop of read(s) that always find an event as it was put back.
That is clearly an application bug and is not the concern of the
kernel..
> I suggest to leave this flow as it's now, at least for this series
> submission.
>
> Agree ?
I don't think you can actually fix this, so maybe we have to leave
it. But add a comment explaining
Jason
^ permalink raw reply
* Re: [PATCH RFC net-next 1/5] net: dsa: mt7530: Convert to PHYLINK API
From: Vladimir Oltean @ 2019-06-25 20:24 UTC (permalink / raw)
To: Russell King - ARM Linux admin, René van Dorst
Cc: sean.wang, f.fainelli, davem, matthias.bgg, andrew,
vivien.didelot, frank-w, netdev, linux-mediatek, linux-mips
In-Reply-To: <20190624153950.hdsuhrvfd77heyor@shell.armlinux.org.uk>
Hi Russell,
On 6/24/19 6:39 PM, Russell King - ARM Linux admin wrote:
> Hi,
>
> On Mon, Jun 24, 2019 at 04:52:47PM +0200, René van Dorst wrote:
>> Convert mt7530 to PHYLINK API
>>
>> Signed-off-by: René van Dorst <opensource@vdorst.com>
>> ---
>> drivers/net/dsa/mt7530.c | 237 +++++++++++++++++++++++++++++----------
>> drivers/net/dsa/mt7530.h | 9 ++
>> 2 files changed, 187 insertions(+), 59 deletions(-)
>>
>> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
>> index 3181e95586d6..9c5e4dd00826 100644
>> --- a/drivers/net/dsa/mt7530.c
>> +++ b/drivers/net/dsa/mt7530.c
>> @@ -13,7 +13,7 @@
>> #include <linux/of_mdio.h>
>> #include <linux/of_net.h>
>> #include <linux/of_platform.h>
>> -#include <linux/phy.h>
>> +#include <linux/phylink.h>
>> #include <linux/regmap.h>
>> #include <linux/regulator/consumer.h>
>> #include <linux/reset.h>
>> @@ -633,63 +633,6 @@ mt7530_get_sset_count(struct dsa_switch *ds, int port, int sset)
>> return ARRAY_SIZE(mt7530_mib);
>> }
>>
>> -static void mt7530_adjust_link(struct dsa_switch *ds, int port,
>> - struct phy_device *phydev)
>> -{
>> - struct mt7530_priv *priv = ds->priv;
>> -
>> - if (phy_is_pseudo_fixed_link(phydev)) {
>> - dev_dbg(priv->dev, "phy-mode for master device = %x\n",
>> - phydev->interface);
>> -
>> - /* Setup TX circuit incluing relevant PAD and driving */
>> - mt7530_pad_clk_setup(ds, phydev->interface);
>> -
>> - if (priv->id == ID_MT7530) {
>> - /* Setup RX circuit, relevant PAD and driving on the
>> - * host which must be placed after the setup on the
>> - * device side is all finished.
>> - */
>> - mt7623_pad_clk_setup(ds);
>> - }
>> - } else {
>> - u16 lcl_adv = 0, rmt_adv = 0;
>> - u8 flowctrl;
>> - u32 mcr = PMCR_USERP_LINK | PMCR_FORCE_MODE;
>> -
>> - switch (phydev->speed) {
>> - case SPEED_1000:
>> - mcr |= PMCR_FORCE_SPEED_1000;
>> - break;
>> - case SPEED_100:
>> - mcr |= PMCR_FORCE_SPEED_100;
>> - break;
>> - }
>> -
>> - if (phydev->link)
>> - mcr |= PMCR_FORCE_LNK;
>> -
>> - if (phydev->duplex) {
>> - mcr |= PMCR_FORCE_FDX;
>> -
>> - if (phydev->pause)
>> - rmt_adv = LPA_PAUSE_CAP;
>> - if (phydev->asym_pause)
>> - rmt_adv |= LPA_PAUSE_ASYM;
>> -
>> - lcl_adv = linkmode_adv_to_lcl_adv_t(
>> - phydev->advertising);
>> - flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
>> -
>> - if (flowctrl & FLOW_CTRL_TX)
>> - mcr |= PMCR_TX_FC_EN;
>> - if (flowctrl & FLOW_CTRL_RX)
>> - mcr |= PMCR_RX_FC_EN;
>> - }
>> - mt7530_write(priv, MT7530_PMCR_P(port), mcr);
>> - }
>> -}
>> -
>> static int
>> mt7530_cpu_port_enable(struct mt7530_priv *priv,
>> int port)
>> @@ -1323,6 +1266,178 @@ mt7530_setup(struct dsa_switch *ds)
>> return 0;
>> }
>>
>> +static void mt7530_phylink_mac_config(struct dsa_switch *ds, int port,
>> + unsigned int mode,
>> + const struct phylink_link_state *state)
>> +{
>> + struct mt7530_priv *priv = ds->priv;
>> + u32 mcr = PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | PMCR_BACKOFF_EN |
>> + PMCR_BACKPR_EN | PMCR_TX_EN | PMCR_RX_EN;
>> +
>> + switch (port) {
>> + case 0: /* Internal phy */
>> + case 1:
>> + case 2:
>> + case 3:
>> + case 4:
>> + if (state->interface != PHY_INTERFACE_MODE_GMII)
>> + goto unsupported;
>> + break;
>> + /* case 5: Port 5 is not supported! */
>> + case 6: /* 1st cpu port */
>> + if (state->interface != PHY_INTERFACE_MODE_RGMII &&
>> + state->interface != PHY_INTERFACE_MODE_TRGMII)
>> + goto unsupported;
>> +
>> + /* Setup TX circuit incluing relevant PAD and driving */
>> + mt7530_pad_clk_setup(ds, state->interface);
>> +
>> + if (priv->id == ID_MT7530) {
>> + /* Setup RX circuit, relevant PAD and driving on the
>> + * host which must be placed after the setup on the
>> + * device side is all finished.
>> + */
>> + mt7623_pad_clk_setup(ds);
>> + }
>> + break;
>> + default:
>> + dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
>> + return;
>> + }
>> +
>> + if (!state->an_enabled || mode == MLO_AN_FIXED) {
>> + mcr |= PMCR_FORCE_MODE;
>> +
>> + if (state->speed == SPEED_1000)
>> + mcr |= PMCR_FORCE_SPEED_1000;
>> + if (state->speed == SPEED_100)
>> + mcr |= PMCR_FORCE_SPEED_100;
>> + if (state->duplex == DUPLEX_FULL)
>> + mcr |= PMCR_FORCE_FDX;
>> + if (state->link || mode == MLO_AN_FIXED)
>> + mcr |= PMCR_FORCE_LNK;
>
> This should be removed - state->link is not for use in mac_config.
> Even in fixed mode, the link can be brought up/down by means of a
> gpio, and this should be dealt with via the mac_link_* functions.
>
What do you mean exactly that state->link is not for use, is that true
in general?
In drivers/net/dsa/sja1105/sja1105_main.c, if I remove the "if
(!state->link)" guard, I see PHYLINK calls with a SPEED_UNKNOWN argument
for ports that are BR_STATE_DISABLED. Is that normal?
>> + if (state->pause || phylink_test(state->advertising, Pause))
>> + mcr |= PMCR_TX_FC_EN | PMCR_RX_FC_EN;
>> + if (state->pause & MLO_PAUSE_TX)
>> + mcr |= PMCR_TX_FC_EN;
>> + if (state->pause & MLO_PAUSE_RX)
>> + mcr |= PMCR_RX_FC_EN;
>
> This is clearly wrong - if any bit in state->pause is set, then we
> end up with both PMCR_TX_FC_EN | PMCR_RX_FC_EN set. If we have Pause
> Pause set in the advertising mask, then both are set. This doesn't
> seem right - are these bits setting the advertisement, or are they
> telling the MAC to use flow control?
>
>> + }
>> +
>> + mt7530_write(priv, MT7530_PMCR_P(port), mcr);
>> +
>> + return;
>> +
>> +unsupported:
>> + dev_err(ds->dev, "%s: P%d: Unsupported phy_interface mode: %d (%s)\n",
>> + __func__, port, state->interface, phy_modes(state->interface));
>> +}
>> +
>> +static void mt7530_phylink_mac_link_down(struct dsa_switch *ds, int port,
>> + unsigned int mode,
>> + phy_interface_t interface)
>> +{
>> + /* Do nothing */
>> +}
>> +
>> +static void mt7530_phylink_mac_link_up(struct dsa_switch *ds, int port,
>> + unsigned int mode,
>> + phy_interface_t interface,
>> + struct phy_device *phydev)
>> +{
>> + /* Do nothing */
>> +}
>
> These two are where you should be forcing the link up or down if
> required (basically, inband modes should let the link come up/down
> irrespective of these functions, otherwise it should be forced.)
>
>> +
>> +static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
>> + unsigned long *supported,
>> + struct phylink_link_state *state)
>> +{
>> + __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
>> +
>> + switch (port) {
>> + case 0: /* Internal phy */
>> + case 1:
>> + case 2:
>> + case 3:
>> + case 4:
>> + if (state->interface != PHY_INTERFACE_MODE_NA &&
>> + state->interface != PHY_INTERFACE_MODE_GMII)
>> + goto unsupported;
>> + break;
>> + /* case 5: Port 5 not supported! */
>> + case 6: /* 1st cpu port */
>> + if (state->interface != PHY_INTERFACE_MODE_RGMII &&
>> + state->interface != PHY_INTERFACE_MODE_TRGMII)
>
> PHY_INTERFACE_MODE_NA ?
>
>> + goto unsupported;
>> + break;
>> + default:
>> + linkmode_zero(supported);
>> + dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
>> + return;
>> + }
>> +
>> + phylink_set(mask, Autoneg);
>> + phylink_set(mask, Pause);
>> + phylink_set(mask, Asym_Pause);
>> + phylink_set(mask, MII);
>> +
>> + phylink_set(mask, 10baseT_Half);
>> + phylink_set(mask, 10baseT_Full);
>> + phylink_set(mask, 100baseT_Half);
>> + phylink_set(mask, 100baseT_Full);
>> + phylink_set(mask, 1000baseT_Full);
>> + phylink_set(mask, 1000baseT_Half);
>
> You seem to be missing phylink_set_port_modes() here.
>
>> +
>> + linkmode_and(supported, supported, mask);
>> + linkmode_and(state->advertising, state->advertising, mask);
>> + return;
>> +
>> +unsupported:
>> + linkmode_zero(supported);
>> + dev_err(ds->dev, "%s: unsupported interface mode: [0x%x] %s\n",
>> + __func__, state->interface, phy_modes(state->interface));
>
> Not a good idea to print this at error level; sometimes we just probe
> for support.
>
> Eg, think about a SFP cage, and a SFP is plugged in that uses a PHY
> interface mode that the MAC can't support - we detect that by the
> validation failing, and printing a more meaningful message in phylink
> itself.
>
>> +}
>> +
>> +static int
>> +mt7530_phylink_mac_link_state(struct dsa_switch *ds, int port,
>> + struct phylink_link_state *state)
>> +{
>> + struct mt7530_priv *priv = ds->priv;
>> + u32 pmsr;
>> +
>> + if (port < 0 || port >= MT7530_NUM_PORTS)
>> + return -EINVAL;
>> +
>> + pmsr = mt7530_read(priv, MT7530_PMSR_P(port));
>> +
>> + state->link = (pmsr & PMSR_LINK);
>> + state->an_complete = state->link;
>> + state->duplex = (pmsr & PMSR_DPX) >> 1;
>> +
>> + switch (pmsr & (PMSR_SPEED_1000 | PMSR_SPEED_100)) {
>> + case 0:
>> + state->speed = SPEED_10;
>> + break;
>> + case PMSR_SPEED_100:
>> + state->speed = SPEED_100;
>> + break;
>> + case PMSR_SPEED_1000:
>> + state->speed = SPEED_1000;
>> + break;
>> + default:
>> + state->speed = SPEED_UNKNOWN;
>> + break;
>> + }
>> +
>> + state->pause = 0;
>> + if (pmsr & PMSR_RX_FC)
>> + state->pause |= MLO_PAUSE_RX;
>> + if (pmsr & PMSR_TX_FC)
>> + state->pause |= MLO_PAUSE_TX;
>> +
>> + return 1;
>> +}
>> +
>> static const struct dsa_switch_ops mt7530_switch_ops = {
>> .get_tag_protocol = mtk_get_tag_protocol,
>> .setup = mt7530_setup,
>> @@ -1331,7 +1446,6 @@ static const struct dsa_switch_ops mt7530_switch_ops = {
>> .phy_write = mt7530_phy_write,
>> .get_ethtool_stats = mt7530_get_ethtool_stats,
>> .get_sset_count = mt7530_get_sset_count,
>> - .adjust_link = mt7530_adjust_link,
>> .port_enable = mt7530_port_enable,
>> .port_disable = mt7530_port_disable,
>> .port_stp_state_set = mt7530_stp_state_set,
>> @@ -1344,6 +1458,11 @@ static const struct dsa_switch_ops mt7530_switch_ops = {
>> .port_vlan_prepare = mt7530_port_vlan_prepare,
>> .port_vlan_add = mt7530_port_vlan_add,
>> .port_vlan_del = mt7530_port_vlan_del,
>> + .phylink_validate = mt7530_phylink_validate,
>> + .phylink_mac_link_state = mt7530_phylink_mac_link_state,
>> + .phylink_mac_config = mt7530_phylink_mac_config,
>> + .phylink_mac_link_down = mt7530_phylink_mac_link_down,
>> + .phylink_mac_link_up = mt7530_phylink_mac_link_up,
>> };
>>
>> static const struct of_device_id mt7530_of_match[] = {
>> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
>> index bfac90f48102..41d9a132ac70 100644
>> --- a/drivers/net/dsa/mt7530.h
>> +++ b/drivers/net/dsa/mt7530.h
>> @@ -198,6 +198,7 @@ enum mt7530_vlan_port_attr {
>> #define PMCR_FORCE_SPEED_100 BIT(2)
>> #define PMCR_FORCE_FDX BIT(1)
>> #define PMCR_FORCE_LNK BIT(0)
>> +#define PMCR_FORCE_LNK_DOWN PMCR_FORCE_MODE
>> #define PMCR_COMMON_LINK (PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | \
>> PMCR_BACKOFF_EN | PMCR_BACKPR_EN | \
>> PMCR_TX_EN | PMCR_RX_EN | \
>> @@ -218,6 +219,14 @@ enum mt7530_vlan_port_attr {
>> PMCR_TX_FC_EN | PMCR_RX_FC_EN)
>>
>> #define MT7530_PMSR_P(x) (0x3008 + (x) * 0x100)
>> +#define PMSR_EEE1G BIT(7)
>> +#define PMSR_EEE100M BIT(6)
>> +#define PMSR_RX_FC BIT(5)
>> +#define PMSR_TX_FC BIT(4)
>> +#define PMSR_SPEED_1000 BIT(3)
>> +#define PMSR_SPEED_100 BIT(2)
>> +#define PMSR_DPX BIT(1)
>> +#define PMSR_LINK BIT(0)
>>
>> /* Register for MIB */
>> #define MT7530_PORT_MIB_COUNTER(x) (0x4000 + (x) * 0x100)
>> --
>> 2.20.1
>>
>>
>
Regards,
-Vladimir
^ permalink raw reply
* Re: [EXT] [PATCH V2] bnx2x: Prevent ptp_task to be rescheduled indefinitely
From: Guilherme Piccoli @ 2019-06-25 20:25 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru, jay.vosburgh@canonical.com
Cc: GR-everest-linux-l2, netdev@vger.kernel.org, Ariel Elior
In-Reply-To: <CAHD1Q_y7v5fVeDRT+KDimQ-RBJMujMCL2DPvdBh==YEJ3+2ZaQ@mail.gmail.com>
Sudarsana, let me ask you something: why does the register is reading
value 0x0 always in the
TX timestamp routine if the RX filter is set to None? This is the main
cause of the thread reschedule
thing.
Of course this thread thing is important to fix, but I was discussing
with my leader here and we
are curious on the reasoning the register is getting 0x0.
Thanks in advance,
Guilherme
^ permalink raw reply
* Re: [RFC PATCH bpf-next] RV32G eBPF JIT
From: Luke Nelson @ 2019-06-25 20:26 UTC (permalink / raw)
To: Jiong Wang
Cc: Luke Nelson, Xi Wang, Palmer Dabbelt, Albert Ou,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Björn Töpel, linux-riscv, linux-kernel,
netdev, bpf
In-Reply-To: <87h88f9bm3.fsf@netronome.com>
On Mon, Jun 24, 2019 at 9:45 AM Jiong Wang <jiong.wang@netronome.com> wrote:
>
> Looks to me 32-bit optimization is not enabled.
>
> If you define bpf_jit_needs_zext to return true
>
> bool bpf_jit_needs_zext(void)
> {
> return true;
> }
>
> Then you don't need to zero high 32-bit when writing 32-bit sub-register
> and you just need to implement the explicit zero extension insn which is a
> special variant of BPF_MOV. This can save quite a few instructions. RV64
> and arches like arm has implemented this, please search
> "aux->verifier_zext".
>
> And there is a doc for this optimization:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/Documentation/bpf/bpf_design_QA.rst#n168
Thanks for the pointer. I'll add this optimization before sending out
an updated version of the patch.
– Luke
^ permalink raw reply
* [PATCH bpf-next] libbpf: fix max() type mismatch for 32bit
From: Ivan Khoronzhuk @ 2019-06-25 20:27 UTC (permalink / raw)
To: ast, netdev; +Cc: daniel, bpf, linux-kernel, Ivan Khoronzhuk
It fixes build error for 32bit caused by type mismatch
size_t/unsigned long.
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
tools/lib/bpf/libbpf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 68f45a96769f..5186b7710430 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -778,7 +778,7 @@ static struct bpf_map *bpf_object__add_map(struct bpf_object *obj)
if (obj->nr_maps < obj->maps_cap)
return &obj->maps[obj->nr_maps++];
- new_cap = max(4ul, obj->maps_cap * 3 / 2);
+ new_cap = max((size_t)4, obj->maps_cap * 3 / 2);
new_maps = realloc(obj->maps, new_cap * sizeof(*obj->maps));
if (!new_maps) {
pr_warning("alloc maps for object failed\n");
--
2.17.1
^ permalink raw reply related
* Re: selftests: bpf: test_libbpf.sh failed at file test_l4lb.o
From: Alexei Starovoitov @ 2019-06-25 20:27 UTC (permalink / raw)
To: Dan Rue
Cc: Andrii Nakryiko, Naresh Kamboju,
open list:KERNEL SELFTEST FRAMEWORK, bpf, Netdev, open list, Xdp,
David S. Miller, Daniel Borkmann, Alexei Starovoitov, Martin Lau,
Yonghong Song, john fastabend, Jesper Dangaard Brouer,
Jakub Kicinski, Shuah Khan
In-Reply-To: <20190625153159.5utnn36dgku5545n@xps.therub.org>
On Tue, Jun 25, 2019 at 8:32 AM Dan Rue <dan.rue@linaro.org> wrote:
>
> On Mon, Jun 24, 2019 at 12:58:15PM -0700, Alexei Starovoitov wrote:
> > On Mon, Jun 24, 2019 at 12:53 PM Dan Rue <dan.rue@linaro.org> wrote:
> > >
> > > I would say if it's not possible to check at runtime, and it requires
> > > clang 9.0, that this test should not be enabled by default.
> >
> > The latest clang is the requirement.
> > If environment has old clang or no clang at all these tests will be failing.
>
> Hi Alexei!
>
> I'm not certain if I'm interpreting you as you intended, but it sounds
> like you're telling me that if the test build environment does not use
> 'latest clang' (i guess latest as of today?), that these tests will
> fail, and that is how it is going to be. If I have that wrong, please
> correct me and disregard the rest of my message.
>
> Please understand where we are coming from. We (and many others) run
> thousands of tests from a lot of test frameworks, and so our environment
> often has mutually exclusive requirements when it comes to things like
> toolchain selection.
>
> We believe, strongly, that a test should not emit a "fail" for a missing
> requirement. Fail is a serious thing, and should be reserved for an
> actual issue that needs to be investigated, reported, and fixed.
>
> This is how we treat test failures - we investigate, report, and fix
> them when possible. When they're not real failures, we waste our time
> (and yours, in this case).
>
> By adding the tests to TEST_GEN_PROGS, you're adding them to the general
> test set that those of us running test farms try to run continuously
> across a wide range of hardware environments and kernel branches.
you run the latest selftests/bpf on the latest kernel, right?
If not than selftests/bpf is not for your setup.
In the past people argued that selftests/bpf should check
features of the kernel and skip when features are not found.
My answer to that was always the same: such changes to selftests
for older kernels need to live out of tree.
selftests/bpf are one to one to the latest kernel.
Often kernel commit X will break selftests and they're fixed
in the commit X+1.
clang, pahole, bpftool, iproute2 provide those features for the kernel.
In other words new kernel features rely on new clang and
other tools and selftests are testing those latest kernel features.
Without new clang many new features cannot be tested exhaustively.
datasec and btf are just few examples.
Hence if your test farm cannot install the latest clang, pahole, etc then
I recommend not to run selftest/bpf.
^ permalink raw reply
* Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
From: David Miller @ 2019-06-25 20:31 UTC (permalink / raw)
To: ssuryaextr; +Cc: netdev, dsahern
In-Reply-To: <20190625103359.31102-1-ssuryaextr@gmail.com>
From: Stephen Suryaputra <ssuryaextr@gmail.com>
Date: Tue, 25 Jun 2019 06:33:59 -0400
> Multicast egress packets has skb_rtable(skb)->rt_iif set to the oif.
> Depending on the socket, these packets might be recirculated back as
> input and raw sockets that are opened for them are bound to the VRF. But
> since skb_rtable(skb) is set and its rt_iif is non-zero, inet_iif()
> function returns rt_iif instead of skb_iif (the VRF netdev). Hence, the
> socket lookup fails.
>
> Signed-off-by: Stephen Suryaputra <ssuryaextr@gmail.com>
David A., please review.
Thank you.
^ permalink raw reply
* Re: [PATCH 1/1] mlx5: Fix build when CONFIG_MLX5_EN_RXNFC is disabled
From: David Miller @ 2019-06-25 20:34 UTC (permalink / raw)
To: jes.sorensen; +Cc: saeedm, netdev, kernel-team, jsorensen
In-Reply-To: <20190625152708.23729-2-Jes.Sorensen@gmail.com>
From: Jes Sorensen <jes.sorensen@gmail.com>
Date: Tue, 25 Jun 2019 11:27:08 -0400
> From: Jes Sorensen <jsorensen@fb.com>
>
> The previous patch broke the build with a static declaration for
> a public function.
>
> Fixes: 8f0916c6dc5c (net/mlx5e: Fix ethtool rxfh commands when CONFIG_MLX5_EN_RXNFC is disabled)
> Signed-off-by: Jes Sorensen <jsorensen@fb.com>
Saeed, I'm assuming I will get this via your next pull request once things
are sorted.
Thanks.
^ permalink raw reply
* Re: [net-next 1/1] tipc: simplify stale link failure criteria
From: David Miller @ 2019-06-25 20:34 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1561477003-25362-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 25 Jun 2019 17:36:43 +0200
> In commit a4dc70d46cf1 ("tipc: extend link reset criteria for stale
> packet retransmission") we made link retransmission failure events
> dependent on the link tolerance, and not only of the number of failed
> retransmission attempts, as we did earlier. This works well. However,
> keeping the original, additional criteria of 99 failed retransmissions
> is now redundant, and may in some cases lead to failure detection
> times in the order of minutes instead of the expected 1.5 sec link
> tolerance value.
>
> We now remove this criteria altogether.
>
> Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
From: David Ahern @ 2019-06-25 20:36 UTC (permalink / raw)
To: Stephen Suryaputra, netdev
In-Reply-To: <f0a47b5d-6477-9a6a-cf5d-6e13f0b4acdc@gmail.com>
On 6/25/19 2:22 PM, David Ahern wrote:
> On 6/25/19 4:33 AM, Stephen Suryaputra wrote:
>> @@ -363,10 +376,20 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
>> #endif
>> ) {
>> struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
>> - if (newskb)
>> + if (newskb) {
>> + /* Reset rt_iif so that inet_iif() will return
>> + * skb->dev->ifIndex which is the VRF device for
>> + * socket lookup. Setting this to VRF ifindex
>> + * causes ipi_ifindex in in_pktinfo to be
>> + * overwritten, see ipv4_pktinfo_prepare().
>> + */
>> + if (netif_is_l3_slave(dev))
>
> seems like the rt_iif is a problem for recirculated mcast packets in
> general, not just ones tied to a VRF.
>
>> + ip_mc_reset_rt_iif(net, rt, newskb);
>> +
>> NF_HOOK(NFPROTO_IPV4, NF_INET_POST_ROUTING,
>> net, sk, newskb, NULL, newskb->dev,
>> ip_mc_finish_output);
>> + }
>> }
>>
>> /* Multicasts with ttl 0 must not go beyond the host */
Also, wouldn't this problem apply to broadcast packets as well if they
get recirculated back up the stack? Maybe then the reset_rt_iif needs to
be done in ip_mc_finish_output.
^ permalink raw reply
* Re: [net-next 1/1] tipc: eliminate unnecessary skb expansion during retransmission
From: David Miller @ 2019-06-25 20:40 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1561478893-31371-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 25 Jun 2019 18:08:13 +0200
> We increase the allocated headroom for the buffer copies to be
> retransmitted. This eliminates the need for the lower stack levels
> (UDP/IP/L2) to expand the headroom in order to add their own headers.
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied.
^ permalink raw reply
* Re: [PATCH RFC net-next 1/5] net: dsa: mt7530: Convert to PHYLINK API
From: Andrew Lunn @ 2019-06-25 20:41 UTC (permalink / raw)
To: Daniel Santos
Cc: Russell King - ARM Linux admin, René van Dorst, sean.wang,
f.fainelli, davem, matthias.bgg, vivien.didelot, frank-w, netdev,
linux-mediatek, linux-mips
In-Reply-To: <4fc51dc4-0eec-30d7-86d1-3404819cf6fe@pobox.com>
On Tue, Jun 25, 2019 at 02:27:55PM -0500, Daniel Santos wrote:
> On 6/25/19 2:02 PM, Andrew Lunn wrote:
> >> But will there still be a mechanism to ignore link partner's advertising
> >> and force these parameters?
> > >From man 1 ethtool:
> >
> > -a --show-pause
> > Queries the specified Ethernet device for pause parameter information.
> >
> > -A --pause
> > Changes the pause parameters of the specified Ethernet device.
> >
> > autoneg on|off
> > Specifies whether pause autonegotiation should be enabled.
> >
> > rx on|off
> > Specifies whether RX pause should be enabled.
> >
> > tx on|off
> > Specifies whether TX pause should be enabled.
> >
> > You need to check the driver to see if it actually implements this
> > ethtool call, but that is how it should be configured.
> >
> > Andrew
> >
> Thank you Andrew,
>
> So in this context, my question is the difference between "enabling" and
> "forcing". Here's that register for the mt7620 (which has an mt7530 on
> its die): https://imgur.com/a/pTk0668 I believe this is also what René
> is seeking clarity on?
Lets start with normal operation. If the MAC supports pause or asym
pause, it calls phy_support_sym_pause() or phy_support_asym_pause().
phylib will then configure the PHY to advertise pause as appropriate.
Once auto-neg has completed, the results of the negotiation are set in
phydev. So phdev->pause and phydev->asym_pause. The MAC callback is
then used to tell the MAC about the autoneg results. The MAC should be
programmed using the values in phdev->pause and phydev->asym_pause.
For ethtool, the MAC driver needs to implement .get_pauseparam and
.set_pauseparam. The set_pauseparam needs to validate the settings,
using phy_validate_pause(). If valid, phy_set_asym_pause() is used to
tell the PHY about the new configuration. This will trigger a new
auto-neg if auto-neg is enabled, and the results will be passed back
in the usual way. If auto-neg is disabled, or pause auto-neg is
disabled, the MAC should configure pause directly based on the
settings passed.
Looking at the data sheet page, you want FORCE_MODE_Pn set. You never
want the MAC directly talking to the PHY. Bad things will happen.
Then use FORCE_RX_FC_Pn and FORCE_TX_Pn to reflect phydev->pause and
phydev->asym_pause.
The same idea applies when using phylink.
Andrew
^ permalink raw reply
* Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
From: Stephen Suryaputra @ 2019-06-25 20:42 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <f0a47b5d-6477-9a6a-cf5d-6e13f0b4acdc@gmail.com>
On Tue, Jun 25, 2019 at 4:22 PM David Ahern <dsahern@gmail.com> wrote:
>
> On 6/25/19 4:33 AM, Stephen Suryaputra wrote:
> > @@ -363,10 +376,20 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
> > #endif
> > ) {
> > struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
> > - if (newskb)
> > + if (newskb) {
> > + /* Reset rt_iif so that inet_iif() will return
> > + * skb->dev->ifIndex which is the VRF device for
> > + * socket lookup. Setting this to VRF ifindex
> > + * causes ipi_ifindex in in_pktinfo to be
> > + * overwritten, see ipv4_pktinfo_prepare().
> > + */
> > + if (netif_is_l3_slave(dev))
>
> seems like the rt_iif is a problem for recirculated mcast packets in
> general, not just ones tied to a VRF.
It seems so to me too but I wonder why this hasn't been seen...
Can I get more feedbacks on this? If there is an agreement to fix this
generally, I will remove the if clause and respin the patch with more
accurate changelog.
>
> > + ip_mc_reset_rt_iif(net, rt, newskb);
> > +
> > NF_HOOK(NFPROTO_IPV4, NF_INET_POST_ROUTING,
> > net, sk, newskb, NULL, newskb->dev,
> > ip_mc_finish_output);
> > + }
> > }
> >
> > /* Multicasts with ttl 0 must not go beyond the host */
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] Revert "net: ena: ethtool: add extra properties retrieval via get_priv_flags"
From: David Miller @ 2019-06-25 20:43 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, nafea, dwmw2, sameehj, zorik, saeedb,
netanel
In-Reply-To: <20190625165956.19278-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Tue, 25 Jun 2019 09:59:56 -0700
> This reverts commit 315c28d2b714 ("net: ena: ethtool: add extra properties retrieval via get_priv_flags").
>
> As discussed at netconf and on the mailing list we can't allow
> for the the abuse of private flags for exposing arbitrary device
> labels.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Amazon folks I think this is entirely reasonable, please ACK.
Thanks.
^ permalink raw reply
* Re: [net-next 1/1] tipc: rename function msg_get_wrapped() to msg_inner_hdr()
From: David Miller @ 2019-06-25 20:43 UTC (permalink / raw)
To: jon.maloy
Cc: netdev, gordan.mihaljevic, tung.q.nguyen, hoang.h.le, canh.d.luu,
ying.xue, tipc-discussion
In-Reply-To: <1561484220-22814-1-git-send-email-jon.maloy@ericsson.com>
From: Jon Maloy <jon.maloy@ericsson.com>
Date: Tue, 25 Jun 2019 19:37:00 +0200
> We rename the inline function msg_get_wrapped() to the more
> comprehensible msg_inner_hdr().
>
> Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Applied, thanks Jon.
^ permalink raw reply
* Re: [PATCH v4 net-next 0/4] net: ethernet: ti: cpsw: Add XDP support
From: David Miller @ 2019-06-25 20:46 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, hawk, brouer, saeedm, leon, ast, linux-kernel,
linux-omap, xdp-newbies, ilias.apalodimas, netdev, daniel,
jakub.kicinski, john.fastabend
In-Reply-To: <20190625175948.24771-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 25 Jun 2019 20:59:44 +0300
> This patchset adds XDP support for TI cpsw driver and base it on
> page_pool allocator. It was verified on af_xdp socket drop,
> af_xdp l2f, ebpf XDP_DROP, XDP_REDIRECT, XDP_PASS, XDP_TX.
So happy to watch the progress of this patch set.
Jesper and others, please review.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next 1/1] tc-testing: add ingress qdisc tests
From: David Miller @ 2019-06-25 20:47 UTC (permalink / raw)
To: mrv; +Cc: netdev, kernel, jhs, xiyou.wangcong, jiri
In-Reply-To: <1561486732-5070-1-git-send-email-mrv@mojatatu.com>
From: Roman Mashak <mrv@mojatatu.com>
Date: Tue, 25 Jun 2019 14:18:52 -0400
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
Applied.
^ permalink raw reply
* What to do when a bridge port gets its pvid deleted?
From: Vladimir Oltean @ 2019-06-25 20:49 UTC (permalink / raw)
To: netdev, Andrew Lunn, Florian Fainelli, Vivien Didelot, stephen
Hi,
A number of DSA drivers (BCM53XX, Microchip KSZ94XX, Mediatek MT7530
at the very least), as well as Mellanox Spectrum (I didn't look at all
the pure switchdev drivers) try to restore the pvid to a default value
on .port_vlan_del.
Sure, the port stops receiving traffic when its pvid is a VLAN ID that
is not installed in its hw filter, but as far as the bridge core is
concerned, this is to be expected:
# bridge vlan add dev swp2 vid 100 pvid untagged
# bridge vlan
port vlan ids
swp5 1 PVID Egress Untagged
swp2 1 Egress Untagged
100 PVID Egress Untagged
swp3 1 PVID Egress Untagged
swp4 1 PVID Egress Untagged
br0 1 PVID Egress Untagged
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.682 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.299 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.251 ms
64 bytes from 10.0.0.1: icmp_seq=4 ttl=64 time=0.324 ms
64 bytes from 10.0.0.1: icmp_seq=5 ttl=64 time=0.257 ms
^C
--- 10.0.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4188ms
rtt min/avg/max/mdev = 0.251/0.362/0.682/0.163 ms
# bridge vlan del dev swp2 vid 100
# bridge vlan
port vlan ids
swp5 1 PVID Egress Untagged
swp2 1 Egress Untagged
swp3 1 PVID Egress Untagged
swp4 1 PVID Egress Untagged
br0 1 PVID Egress Untagged
# ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7267ms
What is the consensus here? Is there a reason why the bridge driver
doesn't take care of this? Do switchdev drivers have to restore the
pvid to always be operational, even if their state becomes
inconsistent with the upper dev? Is it just 'nice to have'? What if
VID 1 isn't in the hw filter either (perfectly legal)?
Thanks!
-Vladimir
^ permalink raw reply
* Re: [PATCH] xsk: Properly terminate assignment in xskq_produce_flush_desc
From: Björn Töpel @ 2019-06-25 20:49 UTC (permalink / raw)
To: Jonathan Lemon
Cc: Nathan Chancellor, Björn Töpel, Magnus Karlsson,
David S. Miller, Alexei Starovoitov, Daniel Borkmann,
Jakub Kicinski, Jesper Dangaard Brouer, John Fastabend, Netdev,
bpf, Xdp, LKML, clang-built-linux, Nick Desaulniers,
Nathan Huckleberry
In-Reply-To: <34F07894-FDE7-44F8-B7F2-E2003D550AD2@gmail.com>
On Tue, 25 Jun 2019 at 22:04, Jonathan Lemon <jonathan.lemon@gmail.com> wrote:
>
>
>
> On 25 Jun 2019, at 11:23, Nathan Chancellor wrote:
>
> > Clang warns:
> >
> > In file included from net/xdp/xsk_queue.c:10:
> > net/xdp/xsk_queue.h:292:2: warning: expression result unused
> > [-Wunused-value]
> > WRITE_ONCE(q->ring->producer, q->prod_tail);
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > include/linux/compiler.h:284:6: note: expanded from macro 'WRITE_ONCE'
> > __u.__val; \
> > ~~~ ^~~~~
> > 1 warning generated.
> >
> > The q->prod_tail assignment has a comma at the end, not a semi-colon.
> > Fix that so clang no longer warns and everything works as expected.
> >
> > Fixes: c497176cb2e4 ("xsk: add Rx receive functions and poll support")
> > Link: https://github.com/ClangBuiltLinux/linux/issues/544
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Nice find.
>
> Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
>
Yikes. Yes, nice find, indeed.
Acked-by: Björn Töpel <bjorn.topel@intel.com>
The broader question is "Why does it work at all?", which is an "oh no" moment.
The problematic functions are xsk_flush() and xsk_generic_rcv, where
xskq_produce_flush_desc() is inlined. On the test machine, the GCC
version is:
$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I when I diff the output, both .lst and .o:
$ diff -u old.lst new.lst
--- old.lst 2019-06-25 22:10:57.709591605 +0200
+++ new.lst 2019-06-25 22:10:35.301359865 +0200
@@ -2480,7 +2480,7 @@
1566: 48 8b 87 e0 02 00 00 mov 0x2e0(%rdi),%rax
{
156d: 48 89 e5 mov %rsp,%rbp
- q->prod_tail = q->prod_head,
+ q->prod_tail = q->prod_head;
1570: 8b 50 18 mov 0x18(%rax),%edx
1573: 89 50 1c mov %edx,0x1c(%rax)
WRITE_ONCE(q->ring->producer, q->prod_tail);
@@ -2649,7 +2649,7 @@
16fb: 83 40 24 01 addl $0x1,0x24(%rax)
xskq_produce_flush_desc(xs->rx);
16ff: 49 8b 86 e0 02 00 00 mov 0x2e0(%r14),%rax
- q->prod_tail = q->prod_head,
+ q->prod_tail = q->prod_head;
1706: 8b 50 18 mov 0x18(%rax),%edx
xs->sk.sk_data_ready(&xs->sk);
1709: 4c 89 f7 mov %r14,%rdi
$ diff -u <(gdb -batch -ex 'file old.o' -ex 'disassemble xsk_flush')
<(gdb -batch -ex 'file new.o' -ex 'disassemble xsk_flush') && echo
"Whew"
Whew
$ diff -u <(gdb -batch -ex 'file old.o' -ex 'disassemble
xsk_generic_rcv') <(gdb -batch -ex 'file new.o' -ex 'disassemble
xsk_generic_rcv') && echo "Whew"
Whew
struct xsk_queue {
u64 chunk_mask; /* 0 0x8 */
u64 size; /* 0x8 0x8 */
u32 ring_mask; /* 0x10 0x4 */
u32 nentries; /* 0x14 0x4 */
u32 prod_head; /* 0x18 0x4 */
u32 prod_tail; /* 0x1c 0x4 */
u32 cons_head; /* 0x20 0x4 */
u32 cons_tail; /* 0x24 0x4 */
struct xdp_ring * ring; /* 0x28 0x8 */
u64 invalid_descs; /* 0x30 0x8 */
/* size: 56, cachelines: 1, members: 10 */
/* last cacheline: 56 bytes */
};
So, it appears that the generated code is equal, both in xsk_flush()
and xsk_generic_rcv() where flush was inlined. I'll be digging into
more GCC versions, and observe the generated code.
Regardless, this was a really good find. Thank you very much! Clang is
added to my kernel build workflow from now on...
Björn
>
> > ---
> > net/xdp/xsk_queue.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/net/xdp/xsk_queue.h b/net/xdp/xsk_queue.h
> > index 88b9ae24658d..cba4a640d5e8 100644
> > --- a/net/xdp/xsk_queue.h
> > +++ b/net/xdp/xsk_queue.h
> > @@ -288,7 +288,7 @@ static inline void xskq_produce_flush_desc(struct
> > xsk_queue *q)
> > /* Order producer and data */
> > smp_wmb(); /* B, matches C */
> >
> > - q->prod_tail = q->prod_head,
> > + q->prod_tail = q->prod_head;
> > WRITE_ONCE(q->ring->producer, q->prod_tail);
> > }
> >
> > --
> > 2.22.0
^ permalink raw reply
* Re: [PATCH bpf-next 0/4] sys_bpf() access control via /dev/bpf
From: Stanislav Fomichev @ 2019-06-25 20:51 UTC (permalink / raw)
To: Song Liu; +Cc: netdev, bpf, ast, daniel, kernel-team
In-Reply-To: <20190625182303.874270-1-songliubraving@fb.com>
On 06/25, Song Liu wrote:
> Currently, most access to sys_bpf() is limited to root. However, there are
> use cases that would benefit from non-privileged use of sys_bpf(), e.g.
> systemd.
>
> This set introduces a new model to control the access to sys_bpf(). A
> special device, /dev/bpf, is introduced to manage access to sys_bpf().
> Users with access to open /dev/bpf will be able to access most of
> sys_bpf() features. The use can get access to sys_bpf() by opening /dev/bpf
> and use ioctl to get/put permission.
>
> The permission to access sys_bpf() is marked by bit TASK_BPF_FLAG_PERMITTED
> in task_struct. During fork(), child will not inherit this bit.
2c: if we are going to have an fd, I'd vote for a proper fd based access
checks instead of a per-task flag, so we can do:
ioctl(fd, BPF_MAP_CREATE, uattr, sizeof(uattr))
(and pass this fd around)
I do understand that it breaks current assumptions that libbpf has,
but maybe we can extend _xattr variants to accept optinal fd (and try
to fallback to sysctl if it's absent/not working)?
> libbpf APIs libbpf_[get|put]_bpf_permission() are added to help get and
> put the permission. bpftool is updated to use these APIs.
>
> Song Liu (4):
> bpf: unprivileged BPF access via /dev/bpf
> bpf: sync tools/include/uapi/linux/bpf.h
> libbpf: add libbpf_[get|put]_bpf_permission()
> bpftool: use libbpf_[get|put]_bpf_permission()
>
> Documentation/ioctl/ioctl-number.txt | 1 +
> include/linux/bpf.h | 12 +++++
> include/linux/sched.h | 8 ++++
> include/uapi/linux/bpf.h | 5 ++
> kernel/bpf/arraymap.c | 2 +-
> kernel/bpf/cgroup.c | 2 +-
> kernel/bpf/core.c | 4 +-
> kernel/bpf/cpumap.c | 2 +-
> kernel/bpf/devmap.c | 2 +-
> kernel/bpf/hashtab.c | 4 +-
> kernel/bpf/lpm_trie.c | 2 +-
> kernel/bpf/offload.c | 2 +-
> kernel/bpf/queue_stack_maps.c | 2 +-
> kernel/bpf/reuseport_array.c | 2 +-
> kernel/bpf/stackmap.c | 2 +-
> kernel/bpf/syscall.c | 72 +++++++++++++++++++++-------
> kernel/bpf/verifier.c | 2 +-
> kernel/bpf/xskmap.c | 2 +-
> kernel/fork.c | 4 ++
> net/core/filter.c | 6 +--
> tools/bpf/bpftool/feature.c | 2 +-
> tools/bpf/bpftool/main.c | 5 ++
> tools/include/uapi/linux/bpf.h | 5 ++
> tools/lib/bpf/libbpf.c | 54 +++++++++++++++++++++
> tools/lib/bpf/libbpf.h | 7 +++
> tools/lib/bpf/libbpf.map | 2 +
> 26 files changed, 178 insertions(+), 35 deletions(-)
>
> --
> 2.17.1
^ permalink raw reply
* Re: [PATCH net] vrf: reset rt_iif for recirculated mcast out pkts
From: David Ahern @ 2019-06-25 20:52 UTC (permalink / raw)
To: Stephen Suryaputra; +Cc: netdev
In-Reply-To: <CAHapkUghFv-DyjY=KtKrJYicJpvRrL1cRa50Gr7tG-H4-10Lzg@mail.gmail.com>
On 6/25/19 2:42 PM, Stephen Suryaputra wrote:
> On Tue, Jun 25, 2019 at 4:22 PM David Ahern <dsahern@gmail.com> wrote:
>>
>> On 6/25/19 4:33 AM, Stephen Suryaputra wrote:
>>> @@ -363,10 +376,20 @@ int ip_mc_output(struct net *net, struct sock *sk, struct sk_buff *skb)
>>> #endif
>>> ) {
>>> struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
>>> - if (newskb)
>>> + if (newskb) {
>>> + /* Reset rt_iif so that inet_iif() will return
>>> + * skb->dev->ifIndex which is the VRF device for
>>> + * socket lookup. Setting this to VRF ifindex
>>> + * causes ipi_ifindex in in_pktinfo to be
>>> + * overwritten, see ipv4_pktinfo_prepare().
>>> + */
>>> + if (netif_is_l3_slave(dev))
>>
>> seems like the rt_iif is a problem for recirculated mcast packets in
>> general, not just ones tied to a VRF.
>
> It seems so to me too but I wonder why this hasn't been seen...
> Can I get more feedbacks on this? If there is an agreement to fix this
> generally, I will remove the if clause and respin the patch with more
> accurate changelog.
rt_iif is used to save the original oif during a route lookup so if
packets are delivered locally apps can know the real oif and not the
loopback/VRF device which is just a trick for local traffic.
The raw socket lookup was recently changed to handle local traffic with
raw sockets bound to a device. e.g., ping was recently changed to use
SO_BINDTODEVICE vs IP_PKTINFO and revealed that the socket lookup was
not considering rt_iif when doing the lookup for 'ping -I <dev> <dev addr>'
The mcast use case seems to get hung up on rt_iif being set when packets
are recirculated for local delivery which is slightly different use case
than local traffic to local addresses.
^ permalink raw reply
* [pull request][for-next V2 0/7] Generic DIM lib for netdev and RDMA
From: Saeed Mahameed @ 2019-06-25 20:57 UTC (permalink / raw)
To: David S. Miller, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Sagi Grimberg, Tal Gilboa,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
Saeed Mahameed
Hi Dave, Doug & Jason
This series improves DIM - Dynamically-tuned Interrupt
Moderation- to be generic for netdev and RDMA use-cases.
From Tal and Yamin:
First 7 patches provide the necessary refactoring to current net_dim
library which affect some net drivers who are using the API.
The last 3 patches provide the RDMA implementation for DIM.
These patches are included in this pull request and they are posted
for review visibility only, they will be handled by the rdma tree later
on in this kernel release.
For more information please see tag log below.
Once we are all happy with the series, please pull to net-next and
rdma-next trees.
v1 for reference:
(https://marc.info/?l=linux-netdev&m=155977708016030&w=2)
Changes since v2:
- added per ib device configuration knob for rdma-dim (Sagi)
- add NL directives for user-space / rdma tool to configure rdma dim (Sagi/Leon)
- use one header file for DIM implementations (Leon)
- various point changes in the rdma dim related code in the IB core (Leon)
- removed the RDMA specific patches form this pull request\
Thanks,
Saeed.
---
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git tags/blk-dim-v2
for you to fetch changes up to 398c2b05bbee21cc172dfff017c0351d4d14e04c:
linux/dim: Add completions count to dim_sample (2019-06-25 13:46:40 -0700)
----------------------------------------------------------------
Generic DIM
From: Tal Gilboa and Yamin Fridman
Implement net DIM over a generic DIM library, add RDMA DIM
dim.h lib exposes an implementation of the DIM algorithm for
dynamically-tuned interrupt moderation for networking interfaces.
We want a similar functionality for other protocols, which might need to
optimize interrupts differently. Main motivation here is DIM for NVMf
storage protocol.
Current DIM implementation prioritizes reducing interrupt overhead over
latency. Also, in order to reduce DIM's own overhead, the algorithm might
take some time to identify it needs to change profiles. While this is
acceptable for networking, it might not work well on other scenarios.
Here we propose a new structure to DIM. The idea is to allow a slightly
modified functionality without the risk of breaking Net DIM behavior for
netdev. We verified there are no degradations in current DIM behavior with
the modified solution.
Suggested solution:
- Common logic is implemented in lib/dim/dim.c
- Net DIM (existing) logic is implemented in lib/dim/net_dim.c, which uses
the common logic in dim.c
- Any new DIM logic will be implemented in "lib/dim/new_dim.c".
This new implementation will expose modified versions of profiles,
dim_step() and dim_decision().
- DIM API is declared in include/linux/dim.h for all implementations.
Pros for this solution are:
- Zero impact on existing net_dim implementation and usage
- Relatively more code reuse (compared to two separate solutions)
- Increased extensibility
----------------------------------------------------------------
Tal Gilboa (6):
linux/dim: Move logic to dim.h
linux/dim: Remove "net" prefix from internal DIM members
linux/dim: Rename externally exposed macros
linux/dim: Rename net_dim_sample() to net_dim_update_sample()
linux/dim: Rename externally used net_dim members
linux/dim: Move implementation to .c files
Yamin Friedman (1):
linux/dim: Add completions count to dim_sample
MAINTAINERS | 3 +-
drivers/net/ethernet/broadcom/Kconfig | 1 +
drivers/net/ethernet/broadcom/bcmsysport.c | 20 +-
drivers/net/ethernet/broadcom/bcmsysport.h | 4 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 12 +-
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 4 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_debugfs.c | 6 +-
drivers/net/ethernet/broadcom/bnxt/bnxt_dim.c | 9 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 18 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en.h | 10 +-
drivers/net/ethernet/mellanox/mlx5/core/en_dim.c | 14 +-
.../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 4 +-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 22 +-
drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 10 +-
include/linux/dim.h | 366 ++++++++++++++++++
include/linux/net_dim.h | 418 ---------------------
lib/Kconfig | 8 +
lib/Makefile | 1 +
lib/dim/Makefile | 9 +
lib/dim/dim.c | 83 ++++
lib/dim/net_dim.c | 190 ++++++++++
23 files changed, 728 insertions(+), 489 deletions(-)
create mode 100644 include/linux/dim.h
delete mode 100644 include/linux/net_dim.h
create mode 100644 lib/dim/Makefile
create mode 100644 lib/dim/dim.c
create mode 100644 lib/dim/net_dim.c
^ permalink raw reply
* [for-next V2 01/10] linux/dim: Move logic to dim.h
From: Saeed Mahameed @ 2019-06-25 20:57 UTC (permalink / raw)
To: David S. Miller, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, Or Gerlitz, Sagi Grimberg, Tal Gilboa,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
Saeed Mahameed
In-Reply-To: <20190625205701.17849-1-saeedm@mellanox.com>
From: Tal Gilboa <talgi@mellanox.com>
In preparation for supporting more implementations of the DIM
algorithm, I'm moving what would become common logic to a common
library. Downstream DIM implementations will use the common lib
for their implementation.
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
MAINTAINERS | 1 +
include/linux/dim.h | 153 ++++++++++++++++++++++++++++++++++++++++
include/linux/net_dim.h | 148 +-------------------------------------
3 files changed, 156 insertions(+), 146 deletions(-)
create mode 100644 include/linux/dim.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 429c6c624861..5d4b852d9d39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5589,6 +5589,7 @@ DYNAMIC INTERRUPT MODERATION
M: Tal Gilboa <talgi@mellanox.com>
S: Maintained
F: include/linux/net_dim.h
+F: include/linux/dim.h
DZ DECSTATION DZ11 SERIAL DRIVER
M: "Maciej W. Rozycki" <macro@linux-mips.org>
diff --git a/include/linux/dim.h b/include/linux/dim.h
new file mode 100644
index 000000000000..67d7ca40f3dd
--- /dev/null
+++ b/include/linux/dim.h
@@ -0,0 +1,153 @@
+/* SPDX-License-Identifier: GPL-2.0 OR Linux-OpenIB */
+/* Copyright (c) 2019 Mellanox Technologies. */
+
+#ifndef DIM_H
+#define DIM_H
+
+#include <linux/module.h>
+
+#define NET_DIM_NEVENTS 64
+
+/* more than 10% difference */
+#define IS_SIGNIFICANT_DIFF(val, ref) \
+ (((100UL * abs((val) - (ref))) / (ref)) > 10)
+#define BIT_GAP(bits, end, start) ((((end) - (start)) + BIT_ULL(bits)) \
+& (BIT_ULL(bits) - 1))
+
+struct net_dim_cq_moder {
+ u16 usec;
+ u16 pkts;
+ u8 cq_period_mode;
+};
+
+struct net_dim_sample {
+ ktime_t time;
+ u32 pkt_ctr;
+ u32 byte_ctr;
+ u16 event_ctr;
+};
+
+struct net_dim_stats {
+ int ppms; /* packets per msec */
+ int bpms; /* bytes per msec */
+ int epms; /* events per msec */
+};
+
+struct net_dim { /* Dynamic Interrupt Moderation */
+ u8 state;
+ struct net_dim_stats prev_stats;
+ struct net_dim_sample start_sample;
+ struct work_struct work;
+ u8 profile_ix;
+ u8 mode;
+ u8 tune_state;
+ u8 steps_right;
+ u8 steps_left;
+ u8 tired;
+};
+
+enum {
+ NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE = 0x0,
+ NET_DIM_CQ_PERIOD_MODE_START_FROM_CQE = 0x1,
+ NET_DIM_CQ_PERIOD_NUM_MODES
+};
+
+enum {
+ NET_DIM_START_MEASURE,
+ NET_DIM_MEASURE_IN_PROGRESS,
+ NET_DIM_APPLY_NEW_PROFILE,
+};
+
+enum {
+ NET_DIM_PARKING_ON_TOP,
+ NET_DIM_PARKING_TIRED,
+ NET_DIM_GOING_RIGHT,
+ NET_DIM_GOING_LEFT,
+};
+
+enum {
+ NET_DIM_STATS_WORSE,
+ NET_DIM_STATS_SAME,
+ NET_DIM_STATS_BETTER,
+};
+
+enum {
+ NET_DIM_STEPPED,
+ NET_DIM_TOO_TIRED,
+ NET_DIM_ON_EDGE,
+};
+
+static inline bool net_dim_on_top(struct net_dim *net_dim)
+{
+ switch (net_dim->tune_state) {
+ case NET_DIM_PARKING_ON_TOP:
+ case NET_DIM_PARKING_TIRED:
+ return true;
+ case NET_DIM_GOING_RIGHT:
+ return (net_dim->steps_left > 1) && (net_dim->steps_right == 1);
+ default: /* NET_DIM_GOING_LEFT */
+ return (net_dim->steps_right > 1) && (net_dim->steps_left == 1);
+ }
+}
+
+static inline void net_dim_turn(struct net_dim *net_dim)
+{
+ switch (net_dim->tune_state) {
+ case NET_DIM_PARKING_ON_TOP:
+ case NET_DIM_PARKING_TIRED:
+ break;
+ case NET_DIM_GOING_RIGHT:
+ net_dim->tune_state = NET_DIM_GOING_LEFT;
+ net_dim->steps_left = 0;
+ break;
+ case NET_DIM_GOING_LEFT:
+ net_dim->tune_state = NET_DIM_GOING_RIGHT;
+ net_dim->steps_right = 0;
+ break;
+ }
+}
+
+static inline void net_dim_park_on_top(struct net_dim *net_dim)
+{
+ net_dim->steps_right = 0;
+ net_dim->steps_left = 0;
+ net_dim->tired = 0;
+ net_dim->tune_state = NET_DIM_PARKING_ON_TOP;
+}
+
+static inline void net_dim_park_tired(struct net_dim *net_dim)
+{
+ net_dim->steps_right = 0;
+ net_dim->steps_left = 0;
+ net_dim->tune_state = NET_DIM_PARKING_TIRED;
+}
+
+static inline void
+net_dim_sample(u16 event_ctr, u64 packets, u64 bytes, struct net_dim_sample *s)
+{
+ s->time = ktime_get();
+ s->pkt_ctr = packets;
+ s->byte_ctr = bytes;
+ s->event_ctr = event_ctr;
+}
+
+static inline void
+net_dim_calc_stats(struct net_dim_sample *start, struct net_dim_sample *end,
+ struct net_dim_stats *curr_stats)
+{
+ /* u32 holds up to 71 minutes, should be enough */
+ u32 delta_us = ktime_us_delta(end->time, start->time);
+ u32 npkts = BIT_GAP(BITS_PER_TYPE(u32), end->pkt_ctr, start->pkt_ctr);
+ u32 nbytes = BIT_GAP(BITS_PER_TYPE(u32), end->byte_ctr,
+ start->byte_ctr);
+
+ if (!delta_us)
+ return;
+
+ curr_stats->ppms = DIV_ROUND_UP(npkts * USEC_PER_MSEC, delta_us);
+ curr_stats->bpms = DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us);
+ curr_stats->epms = DIV_ROUND_UP(NET_DIM_NEVENTS * USEC_PER_MSEC,
+ delta_us);
+}
+
+#endif /* DIM_H */
diff --git a/include/linux/net_dim.h b/include/linux/net_dim.h
index fd458389f7d1..373cda74b167 100644
--- a/include/linux/net_dim.h
+++ b/include/linux/net_dim.h
@@ -35,73 +35,10 @@
#define NET_DIM_H
#include <linux/module.h>
-
-struct net_dim_cq_moder {
- u16 usec;
- u16 pkts;
- u8 cq_period_mode;
-};
-
-struct net_dim_sample {
- ktime_t time;
- u32 pkt_ctr;
- u32 byte_ctr;
- u16 event_ctr;
-};
-
-struct net_dim_stats {
- int ppms; /* packets per msec */
- int bpms; /* bytes per msec */
- int epms; /* events per msec */
-};
-
-struct net_dim { /* Adaptive Moderation */
- u8 state;
- struct net_dim_stats prev_stats;
- struct net_dim_sample start_sample;
- struct work_struct work;
- u8 profile_ix;
- u8 mode;
- u8 tune_state;
- u8 steps_right;
- u8 steps_left;
- u8 tired;
-};
-
-enum {
- NET_DIM_CQ_PERIOD_MODE_START_FROM_EQE = 0x0,
- NET_DIM_CQ_PERIOD_MODE_START_FROM_CQE = 0x1,
- NET_DIM_CQ_PERIOD_NUM_MODES
-};
-
-/* Adaptive moderation logic */
-enum {
- NET_DIM_START_MEASURE,
- NET_DIM_MEASURE_IN_PROGRESS,
- NET_DIM_APPLY_NEW_PROFILE,
-};
-
-enum {
- NET_DIM_PARKING_ON_TOP,
- NET_DIM_PARKING_TIRED,
- NET_DIM_GOING_RIGHT,
- NET_DIM_GOING_LEFT,
-};
-
-enum {
- NET_DIM_STATS_WORSE,
- NET_DIM_STATS_SAME,
- NET_DIM_STATS_BETTER,
-};
-
-enum {
- NET_DIM_STEPPED,
- NET_DIM_TOO_TIRED,
- NET_DIM_ON_EDGE,
-};
+#include <linux/dim.h>
#define NET_DIM_PARAMS_NUM_PROFILES 5
-/* Adaptive moderation profiles */
+/* Netdev dynamic interrupt moderation profiles */
#define NET_DIM_DEFAULT_RX_CQ_MODERATION_PKTS_FROM_EQE 256
#define NET_DIM_DEFAULT_TX_CQ_MODERATION_PKTS_FROM_EQE 128
#define NET_DIM_DEF_PROFILE_CQE 1
@@ -188,36 +125,6 @@ net_dim_get_def_tx_moderation(u8 cq_period_mode)
return net_dim_get_tx_moderation(cq_period_mode, profile_ix);
}
-static inline bool net_dim_on_top(struct net_dim *dim)
-{
- switch (dim->tune_state) {
- case NET_DIM_PARKING_ON_TOP:
- case NET_DIM_PARKING_TIRED:
- return true;
- case NET_DIM_GOING_RIGHT:
- return (dim->steps_left > 1) && (dim->steps_right == 1);
- default: /* NET_DIM_GOING_LEFT */
- return (dim->steps_right > 1) && (dim->steps_left == 1);
- }
-}
-
-static inline void net_dim_turn(struct net_dim *dim)
-{
- switch (dim->tune_state) {
- case NET_DIM_PARKING_ON_TOP:
- case NET_DIM_PARKING_TIRED:
- break;
- case NET_DIM_GOING_RIGHT:
- dim->tune_state = NET_DIM_GOING_LEFT;
- dim->steps_left = 0;
- break;
- case NET_DIM_GOING_LEFT:
- dim->tune_state = NET_DIM_GOING_RIGHT;
- dim->steps_right = 0;
- break;
- }
-}
-
static inline int net_dim_step(struct net_dim *dim)
{
if (dim->tired == (NET_DIM_PARAMS_NUM_PROFILES * 2))
@@ -245,21 +152,6 @@ static inline int net_dim_step(struct net_dim *dim)
return NET_DIM_STEPPED;
}
-static inline void net_dim_park_on_top(struct net_dim *dim)
-{
- dim->steps_right = 0;
- dim->steps_left = 0;
- dim->tired = 0;
- dim->tune_state = NET_DIM_PARKING_ON_TOP;
-}
-
-static inline void net_dim_park_tired(struct net_dim *dim)
-{
- dim->steps_right = 0;
- dim->steps_left = 0;
- dim->tune_state = NET_DIM_PARKING_TIRED;
-}
-
static inline void net_dim_exit_parking(struct net_dim *dim)
{
dim->tune_state = dim->profile_ix ? NET_DIM_GOING_LEFT :
@@ -267,9 +159,6 @@ static inline void net_dim_exit_parking(struct net_dim *dim)
net_dim_step(dim);
}
-#define IS_SIGNIFICANT_DIFF(val, ref) \
- (((100UL * abs((val) - (ref))) / (ref)) > 10) /* more than 10% difference */
-
static inline int net_dim_stats_compare(struct net_dim_stats *curr,
struct net_dim_stats *prev)
{
@@ -351,39 +240,6 @@ static inline bool net_dim_decision(struct net_dim_stats *curr_stats,
return dim->profile_ix != prev_ix;
}
-static inline void net_dim_sample(u16 event_ctr,
- u64 packets,
- u64 bytes,
- struct net_dim_sample *s)
-{
- s->time = ktime_get();
- s->pkt_ctr = packets;
- s->byte_ctr = bytes;
- s->event_ctr = event_ctr;
-}
-
-#define NET_DIM_NEVENTS 64
-#define BIT_GAP(bits, end, start) ((((end) - (start)) + BIT_ULL(bits)) & (BIT_ULL(bits) - 1))
-
-static inline void net_dim_calc_stats(struct net_dim_sample *start,
- struct net_dim_sample *end,
- struct net_dim_stats *curr_stats)
-{
- /* u32 holds up to 71 minutes, should be enough */
- u32 delta_us = ktime_us_delta(end->time, start->time);
- u32 npkts = BIT_GAP(BITS_PER_TYPE(u32), end->pkt_ctr, start->pkt_ctr);
- u32 nbytes = BIT_GAP(BITS_PER_TYPE(u32), end->byte_ctr,
- start->byte_ctr);
-
- if (!delta_us)
- return;
-
- curr_stats->ppms = DIV_ROUND_UP(npkts * USEC_PER_MSEC, delta_us);
- curr_stats->bpms = DIV_ROUND_UP(nbytes * USEC_PER_MSEC, delta_us);
- curr_stats->epms = DIV_ROUND_UP(NET_DIM_NEVENTS * USEC_PER_MSEC,
- delta_us);
-}
-
static inline void net_dim(struct net_dim *dim,
struct net_dim_sample end_sample)
{
--
2.21.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