* Re: [PATCH net-next v5 0/3] hinic: add rss support and rss parameters configuration
From: David Miller @ 2019-06-19 1:52 UTC (permalink / raw)
To: xuechaojing
Cc: linux-kernel, netdev, luoshaokai, cloud.wangxiaoyun, chiqijun,
wulike1
In-Reply-To: <20190618062053.7545-1-xuechaojing@huawei.com>
From: Xue Chaojing <xuechaojing@huawei.com>
Date: Tue, 18 Jun 2019 06:20:50 +0000
> This series add rss support for HINIC driver and implement the ethtool
> interface related to rss parameter configuration. user can use ethtool
> configure rss parameters or show rss parameters.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net/ipv4: fib_trie: Avoid cryptic ternary expressions
From: Alexander Duyck @ 2019-06-19 2:00 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Nathan Chancellor, David S . Miller, Alexey Kuznetsov,
Hideaki YOSHIFUJI, Netdev, LKML, Douglas Anderson,
Nick Desaulniers, Nathan Huckleberry, clang-built-linux
In-Reply-To: <20190618232140.GW137143@google.com>
On Tue, Jun 18, 2019 at 4:22 PM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> On Tue, Jun 18, 2019 at 04:04:20PM -0700, Nathan Chancellor wrote:
> > On Tue, Jun 18, 2019 at 02:14:40PM -0700, Matthias Kaehlcke wrote:
> > > empty_child_inc/dec() use the ternary operator for conditional
> > > operations. The conditions involve the post/pre in/decrement
> > > operator and the operation is only performed when the condition
> > > is *not* true. This is hard to parse for humans, use a regular
> > > 'if' construct instead and perform the in/decrement separately.
> > >
> > > This also fixes two warnings that are emitted about the value
> > > of the ternary expression being unused, when building the kernel
> > > with clang + "kbuild: Remove unnecessary -Wno-unused-value"
> > > (https://lore.kernel.org/patchwork/patch/1089869/):
> > >
> > > CC net/ipv4/fib_trie.o
> > > net/ipv4/fib_trie.c:351:2: error: expression result unused [-Werror,-Wunused-value]
> > > ++tn_info(n)->empty_children ? : ++tn_info(n)->full_children;
> > >
> >
> > As an FYI, this is also being fixed in clang:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=42239
> >
> > https://reviews.llvm.org/D63369
>
> Great, thanks!
>
> In this case it was actually useful to get the warning, even though it
> didn't point out the actual bug. I think in general it would be
> preferable to avoid such constructs, even when they are correct. But
> then again, it's the reviewers/maintainers task to avoid unnecessarily
> cryptic code from slipping in, and this just happens to be one instance
> where the compiler could have helped.
So it took me a bit to remember/understand it as well since I haven't
touched the code in over 4 years, however part of that is because the
comment for this code is actually buried down in put_child.
Essentially this is just meant to be an add w/ carry and a sub w/
borrow to address a potential overflow if bits == KEYLENGTH.
If you want you can add:
Fixes: 95f60ea3e99a ("fib_trie: Add collapse() and should_collapse() to resize")
Acked-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 0/2] Add macb support for SiFive FU540-C000
From: David Miller @ 2019-06-19 2:02 UTC (permalink / raw)
To: yash.shah
Cc: devicetree, netdev, linux-kernel, linux-riscv, robh+dt,
mark.rutland, nicolas.ferre, palmer, aou, paul.walmsley, ynezz,
sachin.ghadi
In-Reply-To: <1560844568-4746-1-git-send-email-yash.shah@sifive.com>
From: Yash Shah <yash.shah@sifive.com>
Date: Tue, 18 Jun 2019 13:26:06 +0530
> On FU540, the management IP block is tightly coupled with the Cadence
> MACB IP block. It manages many of the boundary signals from the MACB IP
> This patchset controls the tx_clk input signal to the MACB IP. It
> switches between the local TX clock (125MHz) and PHY TX clocks. This
> is necessary to toggle between 1Gb and 100/10Mb speeds.
>
> Future patches may add support for monitoring or controlling other IP
> boundary signals.
>
> This patchset is mostly based on work done by
> Wesley Terpstra <wesley@sifive.com>
>
> This patchset is based on Linux v5.2-rc1 and tested on HiFive Unleashed
> board with additional board related patches needed for testing can be
> found at dev/yashs/ethernet_v3 branch of:
> https://github.com/yashshah7/riscv-linux.git
>
> Change History:
...
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: mvpp2: cls: Allow steering based on vlan tag
From: David Miller @ 2019-06-19 2:26 UTC (permalink / raw)
To: maxime.chevallier
Cc: netdev, linux-kernel, antoine.tenart, thomas.petazzoni,
gregory.clement, miquel.raynal, nadavh, stefanc, mw,
linux-arm-kernel
In-Reply-To: <20190618145519.27705-1-maxime.chevallier@bootlin.com>
From: Maxime Chevallier <maxime.chevallier@bootlin.com>
Date: Tue, 18 Jun 2019 16:55:15 +0200
> The PPv2 classifier can perform flow steering based on keys extracted
> from the VLAN tag. This series adds support for using the vlan id and
> the vlan prio as keys, using the ethtool interface.
>
> Patch 1 is a preparatory patch that prevent false-positive matches,
> using a dedicated lookup id for the RSS C2 lookup.
>
> Patch 2 allows to separate the flows based on the header fields they
> contain. The main goal is to be able to separate tagged traffic from
> untagged traffic for flow steering, just as we already do for RSS.
>
> Patch 3 solves an issue we have when extracting fields that aren't full
> bytes, such as the vlan tag which is 12 bits wide, or the priority which
> is 3 bits wide.
>
> Finally, patch 4 adds support for steering based on both vlan id and
> priority, extracted from the outermost tag.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH][next] net/mlx5: add missing void argument to function mlx5_devlink_alloc
From: David Miller @ 2019-06-19 2:30 UTC (permalink / raw)
To: colin.king
Cc: saeedm, leon, netdev, linux-rdma, kernel-janitors, linux-kernel
In-Reply-To: <20190618151510.18672-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 18 Jun 2019 16:15:10 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Function mlx5_devlink_alloc is missing a void argument, add it
> to clean up the non-ANSI function declaration.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: mvpp2: cls: Add pmap to fs dump
From: David Miller @ 2019-06-19 2:33 UTC (permalink / raw)
To: nhuck; +Cc: maxime.chevallier, netdev, linux-kernel, clang-built-linux
In-Reply-To: <20190618160910.62922-1-nhuck@google.com>
From: Nathan Huckleberry <nhuck@google.com>
Date: Tue, 18 Jun 2019 09:09:10 -0700
> + ddebugfs_create_file("pmap", 0444, prs_entry_dir, entry,
drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c: In function ‘mvpp2_dbgfs_prs_entry_init’:
drivers/net/ethernet/marvell/mvpp2/mvpp2_debugfs.c:569:2: error: implicit declaration of function ‘ddebugfs_create_file’; did you mean ‘debugfs_create_file’? [-Werror=implicit-function-declaration]
This doesn't compile, did you build test this?
^ permalink raw reply
* Re: [RFC net-next 1/5] net: stmmac: introduce IEEE 802.1Qbv configuration functionalities
From: Andrew Lunn @ 2019-06-19 3:07 UTC (permalink / raw)
To: Voon Weifeng
Cc: David S. Miller, Maxime Coquelin, netdev, linux-kernel,
Jose Abreu, Giuseppe Cavallaro, Florian Fainelli,
Alexandre Torgue, Vinicius Costa Gomes, Ong Boon Leong
In-Reply-To: <1560893778-6838-2-git-send-email-weifeng.voon@intel.com>
On Wed, Jun 19, 2019 at 05:36:14AM +0800, Voon Weifeng wrote:
Hi Voon
> +static int est_poll_srwo(void *ioaddr)
> +{
> + /* Poll until the EST GCL Control[SRWO] bit clears.
> + * Total wait = 12 x 50ms ~= 0.6s.
> + */
> + unsigned int retries = 12;
> + unsigned int value;
> +
> + do {
> + value = TSN_RD32(ioaddr + MTL_EST_GCL_CTRL);
> + if (!(value & MTL_EST_GCL_CTRL_SRWO))
> + return 0;
> + msleep(50);
> + } while (--retries);
> +
> + return -ETIMEDOUT;
Maybe use one of the readx_poll_timeout() macros?
> +static int est_read_gce(void *ioaddr, unsigned int row,
> + unsigned int *gates, unsigned int *ti_nsec,
> + unsigned int dbgb, unsigned int dbgm)
> +{
> + struct tsn_hw_cap *cap = &dw_tsn_hwcap;
> + unsigned int ti_wid = cap->ti_wid;
> + unsigned int gates_mask;
> + unsigned int ti_mask;
> + unsigned int value;
> + int ret;
> +
> + gates_mask = (1 << cap->txqcnt) - 1;
> + ti_mask = (1 << ti_wid) - 1;
> +
> + ret = est_read_gcl_config(ioaddr, &value, row, 0, dbgb, dbgm);
> + if (ret) {
> + TSN_ERR("Read GCE failed! row=%u\n", row);
It is generally not a good idea to put wrappers around the kernel
print functions. It would be better if all these functions took struct
stmmac_priv *priv rather than ioaddr, so you could then do
netdev_err(priv->dev, "Read GCE failed! row=%u\n", row);
> + /* Ensure that HW is not in the midst of GCL transition */
> + value = TSN_RD32(ioaddr + MTL_EST_CTRL);
Also, don't put wrapper around readl()/writel().
> + value &= ~MTL_EST_CTRL_SSWL;
> +
> + /* MTL_EST_CTRL value has been read earlier, if TILS value
> + * differs, we update here.
> + */
> + if (tils != dw_tsn_hwtunable[TSN_HWTUNA_TX_EST_TILS]) {
> + value &= ~MTL_EST_CTRL_TILS;
> + value |= (tils << MTL_EST_CTRL_TILS_SHIFT);
> +
> + TSN_WR32(value, ioaddr + MTL_EST_CTRL);
> + dw_tsn_hwtunable[TSN_HWTUNA_TX_EST_TILS] = tils;
> + }
> +
> + return 0;
> +}
> +
> +static int est_set_ov(void *ioaddr,
> + const unsigned int *ptov,
> + const unsigned int *ctov)
> +{
> + unsigned int value;
> +
> + if (!dw_tsn_feat_en[TSN_FEAT_ID_EST])
> + return -ENOTSUPP;
> +
> + value = TSN_RD32(ioaddr + MTL_EST_CTRL);
> + value &= ~MTL_EST_CTRL_SSWL;
> +
> + if (ptov) {
> + if (*ptov > EST_PTOV_MAX) {
> + TSN_WARN("EST: invalid PTOV(%u), max=%u\n",
> + *ptov, EST_PTOV_MAX);
It looks like most o the TSN_WARN should actually be netdev_dbg().
Andrew
^ permalink raw reply
* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2019-06-19 3:23 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Kevin Darbyshire-Bryant, Masahiro Yamada
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1:
./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration]
CTINFO_MODE_DSCP = BIT(0),
^~~
./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant
CTINFO_MODE_DSCP = BIT(0),
^~~~~~~~~~~~~~~~
./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant
};
^
Caused by commit
24ec483cec98 ("net: sched: Introduce act_ctinfo action")
Presumably exposed by commit
b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")
from the kbuild tree.
I have applied the following (obvious) patch for today.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 19 Jun 2019 13:15:22 +1000
Subject: [PATCH] net: sched: don't use BIT() in uapi headers
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h
index da803e05a89b..6166c62dd7dd 100644
--- a/include/uapi/linux/tc_act/tc_ctinfo.h
+++ b/include/uapi/linux/tc_act/tc_ctinfo.h
@@ -27,8 +27,8 @@ enum {
#define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1)
enum {
- CTINFO_MODE_DSCP = BIT(0),
- CTINFO_MODE_CPMARK = BIT(1)
+ CTINFO_MODE_DSCP = (1UL << 0),
+ CTINFO_MODE_CPMARK = (1UL << 1)
};
#endif
--
2.20.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* Re: [PATCH net-next] netfilter: bridge: add nft_bridge_pvid to tag the default pvid for non-tagged packet
From: wenxu @ 2019-06-19 3:47 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: fw, netfilter-devel, netdev
In-Reply-To: <20190618164007.suuaa5zx2b242ey7@salvia>
On 6/19/2019 12:40 AM, Pablo Neira Ayuso wrote:
> On Sat, Jun 15, 2019 at 08:14:21PM +0800, wenxu@ucloud.cn wrote:
> [...]
>> +static void nft_bridge_pvid_eval(const struct nft_expr *expr,
>> + struct nft_regs *regs,
>> + const struct nft_pktinfo *pkt)
>> +{
>> + struct sk_buff *skb = pkt->skb;
>> + struct net_bridge_port *p;
>> +
>> + p = br_port_get_rtnl_rcu(skb->dev);
>> +
>> + if (p && br_opt_get(p->br, BROPT_VLAN_ENABLED) &&
>> + !skb_vlan_tag_present(skb)) {
>> + u16 pvid = br_get_pvid(nbp_vlan_group_rcu(p));
>> +
>> + if (pvid)
>> + __vlan_hwaccel_put_tag(skb, p->br->vlan_proto, pvid);
> I see two things here:
>
> #1 Extend new NFT_META_BRIDGE_PVID nft_meta to fetch of 'pvid',
> probably add net/bridge/netfilter/nft_meta_bridge.c for this.
I can get this, it provide a bridge pvid (get meta). But why put it in
nft_meta_bridge.c but not nft_meta.c?
>
> #2 Extend nft_meta to allow to set the vlan tag via
> __vlan_hwaccel_put_tag().
why there is also extend nft_meta? So it's a set meta. Is "vlan id set"
not base on nft_payload ?
>
> If these two changes are in place, then it should be possible to set
> skbuff vlan id based on the pvid, if this is what you need.
>
> This would allow for:
>
> vlan id set bridge pvid
>
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Masahiro Yamada @ 2019-06-19 4:02 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux Next Mailing List,
Linux Kernel Mailing List, Kevin Darbyshire-Bryant
In-Reply-To: <20190619132326.1846345b@canb.auug.org.au>
Hi.
On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1:
> ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration]
> CTINFO_MODE_DSCP = BIT(0),
> ^~~
> ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant
> CTINFO_MODE_DSCP = BIT(0),
> ^~~~~~~~~~~~~~~~
> ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant
> };
> ^
>
> Caused by commit
>
> 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
>
> Presumably exposed by commit
>
> b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")
>
> from the kbuild tree.
My commit correctly blocked the broken UAPI header, Hooray!
People export more and more headers that
are never able to compile in user-space.
We must block new breakages from coming in.
BIT() is not exported to user-space
since it is not prefixed with underscore.
You can use _BITUL() in user-space,
which is available in include/uapi/linux/const.h
Thanks.
> I have applied the following (obvious) patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Wed, 19 Jun 2019 13:15:22 +1000
> Subject: [PATCH] net: sched: don't use BIT() in uapi headers
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> include/uapi/linux/tc_act/tc_ctinfo.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/tc_act/tc_ctinfo.h b/include/uapi/linux/tc_act/tc_ctinfo.h
> index da803e05a89b..6166c62dd7dd 100644
> --- a/include/uapi/linux/tc_act/tc_ctinfo.h
> +++ b/include/uapi/linux/tc_act/tc_ctinfo.h
> @@ -27,8 +27,8 @@ enum {
> #define TCA_CTINFO_MAX (__TCA_CTINFO_MAX - 1)
>
> enum {
> - CTINFO_MODE_DSCP = BIT(0),
> - CTINFO_MODE_CPMARK = BIT(1)
> + CTINFO_MODE_DSCP = (1UL << 0),
> + CTINFO_MODE_CPMARK = (1UL << 1)
> };
>
> #endif
> --
> 2.20.1
>
> --
> Cheers,
> Stephen Rothwell
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Masahiro Yamada @ 2019-06-19 4:14 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Linux Next Mailing List,
Linux Kernel Mailing List, Kevin Darbyshire-Bryant
In-Reply-To: <CAK7LNAQCe0APJ3ggJYRDf_DjYg=dH9+2nNsYoygiFKhTa=givg@mail.gmail.com>
On Wed, Jun 19, 2019 at 1:02 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Hi.
>
>
> On Wed, Jun 19, 2019 at 12:23 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > In file included from usr/include/linux/tc_act/tc_ctinfo.hdrtest.c:1:
> > ./usr/include/linux/tc_act/tc_ctinfo.h:30:21: error: implicit declaration of function 'BIT' [-Werror=implicit-function-declaration]
> > CTINFO_MODE_DSCP = BIT(0),
> > ^~~
> > ./usr/include/linux/tc_act/tc_ctinfo.h:30:2: error: enumerator value for 'CTINFO_MODE_DSCP' is not an integer constant
> > CTINFO_MODE_DSCP = BIT(0),
> > ^~~~~~~~~~~~~~~~
> > ./usr/include/linux/tc_act/tc_ctinfo.h:32:1: error: enumerator value for 'CTINFO_MODE_CPMARK' is not an integer constant
> > };
> > ^
> >
> > Caused by commit
> >
> > 24ec483cec98 ("net: sched: Introduce act_ctinfo action")
> >
> > Presumably exposed by commit
> >
> > b91976b7c0e3 ("kbuild: compile-test UAPI headers to ensure they are self-contained")
> >
> > from the kbuild tree.
>
>
> My commit correctly blocked the broken UAPI header, Hooray!
>
> People export more and more headers that
> are never able to compile in user-space.
>
> We must block new breakages from coming in.
>
>
> BIT() is not exported to user-space
> since it is not prefixed with underscore.
>
>
> You can use _BITUL() in user-space,
> which is available in include/uapi/linux/const.h
>
>
I just took a look at
include/uapi/linux/tc_act/tc_ctinfo.h
I just wondered why the following can be compiled:
struct tc_ctinfo {
tc_gen;
};
Then, I found 'tc_gen' is a macro.
#define tc_gen \
__u32 index; \
__u32 capab; \
int action; \
int refcnt; \
int bindcnt
What a hell.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH mlx5-next 11/15] RDMA/mlx5: Add vport metadata matching for IB representors
From: Jianbo Liu @ 2019-06-19 4:44 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Saeed Mahameed, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Roi Dayan, Mark Bloch
In-Reply-To: <20190618101928.GE4690@mtr-leonro.mtl.com>
The 06/18/2019 18:19, Leon Romanovsky wrote:
> On Mon, Jun 17, 2019 at 07:23:30PM +0000, Saeed Mahameed wrote:
> > From: Jianbo Liu <jianbol@mellanox.com>
> >
> > If vport metadata matching is enabled in eswitch, the rule created
> > must be changed to match on the metadata, instead of source port.
> >
> > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > ---
> > drivers/infiniband/hw/mlx5/ib_rep.c | 11 +++++++
> > drivers/infiniband/hw/mlx5/ib_rep.h | 16 ++++++++++
> > drivers/infiniband/hw/mlx5/main.c | 45 +++++++++++++++++++++++------
> > 3 files changed, 63 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
> > index 22e651cb5534..d4ed611de35d 100644
> > --- a/drivers/infiniband/hw/mlx5/ib_rep.c
> > +++ b/drivers/infiniband/hw/mlx5/ib_rep.c
> > @@ -131,6 +131,17 @@ struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw, int vport)
> > return mlx5_eswitch_vport_rep(esw, vport);
> > }
> >
> > +u32 mlx5_ib_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch *esw)
> > +{
> > + return mlx5_eswitch_vport_match_metadata_enabled(esw);
> > +}
> > +
> > +u32 mlx5_ib_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> > + u16 vport)
> > +{
> > + return mlx5_eswitch_get_vport_metadata_for_match(esw, vport);
> > +}
>
> 1. There is no need to introduce one line functions, call to that code directly.
No. They are in IB, and we don't want them be mixed up by the original
functions in eswitch. Please ask Mark more about it.
> 2. It should be bool and not u32.
>
> Thanks
--
^ permalink raw reply
* Re: [PATCH rdma-next v1 00/12] DEVX asynchronous events
From: Leon Romanovsky @ 2019-06-19 4:45 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Jason Gunthorpe, dledford@redhat.com, Yishai Hadas,
netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <19107c92279cf4ad4d870fa54514423c5e46b748.camel@mellanox.com>
On Tue, Jun 18, 2019 at 06:51:45PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-06-18 at 20:15 +0300, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@mellanox.com>
> >
> > Changelog:
> > v0 -> v1:
>
> Normally 1st submission is V1 and 2nd is V2.
> so this should have been v1->v2.
"Normally" depends on the language you are using. In C, everything
starts from 0, including version of patches :).
>
> For mlx5-next patches:
>
> Acked-by: Saeed Mahameed <saeedm@mellanox.com>
Thanks
^ permalink raw reply
* Re: [PATCH mlx5-next 14/15] {IB, net}/mlx5: E-Switch, Use index of rep for vport to IB port mapping
From: Leon Romanovsky @ 2019-06-19 5:00 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Parav Pandit, Mark Bloch, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Bodong Wang
In-Reply-To: <7b098b42a51e5b96eca99c024719eebafa775f7a.camel@mellanox.com>
On Tue, Jun 18, 2019 at 06:25:46PM +0000, Saeed Mahameed wrote:
> On Tue, 2019-06-18 at 10:47 +0000, Parav Pandit wrote:
> > Hi Leon,
> >
> > > -----Original Message-----
> > > From: Leon Romanovsky
> > > Sent: Tuesday, June 18, 2019 4:12 PM
> > > To: Saeed Mahameed <saeedm@mellanox.com>
> > > Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Bodong Wang
> > > <bodong@mellanox.com>; Parav Pandit <parav@mellanox.com>; Mark
> > > Bloch
> > > <markb@mellanox.com>
> > > Subject: Re: [PATCH mlx5-next 14/15] {IB, net}/mlx5: E-Switch, Use
> > > index of rep
> > > for vport to IB port mapping
> > >
> > > On Mon, Jun 17, 2019 at 07:23:37PM +0000, Saeed Mahameed wrote:
> > > > From: Bodong Wang <bodong@mellanox.com>
> > > >
> > > > In the single IB device mode, the mapping between vport number
> > > > and rep
> > > > relies on a counter. However for dynamic vport allocation, it is
> > > > desired to keep consistent map of eswitch vport and IB port.
> > > >
> > > > Hence, simplify code to remove the free running counter and
> > > > instead
> > > > use the available vport index during load/unload sequence from
> > > > the
> > > > eswitch.
> > > >
> > > > Signed-off-by: Bodong Wang <bodong@mellanox.com>
> > > > Suggested-by: Parav Pandit <parav@mellanox.com>
> > > > Reviewed-by: Parav Pandit <parav@mellanox.com>
> > >
> > > We are not adding multiple "*-by" for same user, please choose one.
> > >
> > Suggested-by was added by Bodong during our discussion. Later on when
> > I did gerrit +1, RB tag got added.
> >
>
> Is there a rule against having multiple "*-by" ? i don't think so and
> there shouldn't be, users need to get the exact amount of recognition
> as the amount of work they put into this patch, if they reviewed and
> tested a patch they deserve two tags ..
Not everything in the world has and needs rules, sometimes common sense
is enough. It goes without saying that during internal review process,
developer suggested something. Recognition comes in many ways in the
kernel but definitely not by number of tags with specific developer
name on it, especially if this developer comes from same company
as patch author.
If we extend your claim, both you and me should add this type of
signature block for almost every patch which we submit:
Reviewed-by: ....
Tested-by: ....
Suggested-by: ...
Signed-by: ...
Thanks
>
>
^ permalink raw reply
* Re: [PATCH mlx5-next 11/15] RDMA/mlx5: Add vport metadata matching for IB representors
From: Leon Romanovsky @ 2019-06-19 5:04 UTC (permalink / raw)
To: Jianbo Liu
Cc: Saeed Mahameed, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Roi Dayan, Mark Bloch
In-Reply-To: <20190619044420.GA30694@mellanox.com>
On Wed, Jun 19, 2019 at 04:44:26AM +0000, Jianbo Liu wrote:
> The 06/18/2019 18:19, Leon Romanovsky wrote:
> > On Mon, Jun 17, 2019 at 07:23:30PM +0000, Saeed Mahameed wrote:
> > > From: Jianbo Liu <jianbol@mellanox.com>
> > >
> > > If vport metadata matching is enabled in eswitch, the rule created
> > > must be changed to match on the metadata, instead of source port.
> > >
> > > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > > ---
> > > drivers/infiniband/hw/mlx5/ib_rep.c | 11 +++++++
> > > drivers/infiniband/hw/mlx5/ib_rep.h | 16 ++++++++++
> > > drivers/infiniband/hw/mlx5/main.c | 45 +++++++++++++++++++++++------
> > > 3 files changed, 63 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
> > > index 22e651cb5534..d4ed611de35d 100644
> > > --- a/drivers/infiniband/hw/mlx5/ib_rep.c
> > > +++ b/drivers/infiniband/hw/mlx5/ib_rep.c
> > > @@ -131,6 +131,17 @@ struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw, int vport)
> > > return mlx5_eswitch_vport_rep(esw, vport);
> > > }
> > >
> > > +u32 mlx5_ib_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch *esw)
> > > +{
> > > + return mlx5_eswitch_vport_match_metadata_enabled(esw);
> > > +}
> > > +
> > > +u32 mlx5_ib_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> > > + u16 vport)
> > > +{
> > > + return mlx5_eswitch_get_vport_metadata_for_match(esw, vport);
> > > +}
> >
> > 1. There is no need to introduce one line functions, call to that code directly.
>
> No. They are in IB, and we don't want them be mixed up by the original
> functions in eswitch. Please ask Mark more about it.
Please enlighten me.
>
> > 2. It should be bool and not u32.
> >
> > Thanks
>
> --
^ permalink raw reply
* Re: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs
From: Jianbo Liu @ 2019-06-19 5:12 UTC (permalink / raw)
To: Parav Pandit
Cc: Saeed Mahameed, Leon Romanovsky, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Eli Britstein, Roi Dayan, Mark Bloch
In-Reply-To: <AM0PR05MB48664868E0B89E582807830BD1EA0@AM0PR05MB4866.eurprd05.prod.outlook.com>
The 06/18/2019 18:31, Parav Pandit wrote:
>
>
> > -----Original Message-----
> > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> > Behalf Of Saeed Mahameed
> > Sent: Tuesday, June 18, 2019 12:53 AM
> > To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> > <leonro@mellanox.com>
> > Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> > <jianbol@mellanox.com>; Eli Britstein <elibr@mellanox.com>; Roi Dayan
> > <roid@mellanox.com>; Mark Bloch <markb@mellanox.com>
> > Subject: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport
> > number in VF vports and uplink ingress ACLs
> >
> > From: Jianbo Liu <jianbol@mellanox.com>
> >
> > When a dual-port VHCA sends a RoCE packet on its non-native port, and the
> > packet arrives to its affiliated vport FDB, a mismatch might occur on the rules
> > that match the packet source vport as it is not represented by single VHCA only
> > in this case. So we change to match on metadata instead of source vport.
> > To do that, a rule is created in all vports and uplink ingress ACLs, to save the
> > source vport number and vhca id in the packet's metadata in order to match on
> > it later.
> > The metadata register used is the first of the 32-bit type C registers. It can be
> > used for matching and header modify operations. The higher 16 bits of this
> > register are for vhca id, and the lower 16 ones is for vport number.
> > This change is not for dual-port RoCE only. If HW and FW allow, the vport
> > metadata matching is enabled by default.
> >
> > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > Reviewed-by: Eli Britstein <elibr@mellanox.com>
> > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > ---
> > .../net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +
> > .../net/ethernet/mellanox/mlx5/core/eswitch.h | 9 +
> > .../mellanox/mlx5/core/eswitch_offloads.c | 183 ++++++++++++++----
> > include/linux/mlx5/eswitch.h | 3 +
> > 4 files changed, 161 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > index a42a23e505df..1235fd84ae3a 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > @@ -1168,6 +1168,8 @@ void esw_vport_cleanup_ingress_rules(struct
> > mlx5_eswitch *esw,
> >
> > vport->ingress.drop_rule = NULL;
> > vport->ingress.allow_rule = NULL;
> > +
> > + esw_vport_del_ingress_acl_modify_metadata(esw, vport);
> > }
> >
> > void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw, diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > index 8b9f2cf58e91..4417a195832e 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > @@ -68,6 +68,8 @@ struct vport_ingress {
> > struct mlx5_flow_group *allow_spoofchk_only_grp;
> > struct mlx5_flow_group *allow_untagged_only_grp;
> > struct mlx5_flow_group *drop_grp;
> > + int modify_metadata_id;
> No need for random alignment. Just have one white space after int.
Not random. It's to align with other lines in the this structure.
There are also other fileds with more than one spaces after type.
It looks ugly if there are different styles in the same structure.
>
> > + struct mlx5_flow_handle *modify_metadata_rule;
> > struct mlx5_flow_handle *allow_rule;
> > struct mlx5_flow_handle *drop_rule;
> > struct mlx5_fc *drop_counter;
> > @@ -196,6 +198,10 @@ struct mlx5_esw_functions {
> > u16 num_vfs;
> > };
> >
> > +enum {
> > + MLX5_ESWITCH_VPORT_MATCH_METADATA = BIT(0), };
> > +
> > struct mlx5_eswitch {
> > struct mlx5_core_dev *dev;
> > struct mlx5_nb nb;
> > @@ -203,6 +209,7 @@ struct mlx5_eswitch {
> > struct hlist_head mc_table[MLX5_L2_ADDR_HASH_SIZE];
> > struct workqueue_struct *work_queue;
> > struct mlx5_vport *vports;
> > + u32 flags;
> Same as above, no need for extra aligment.
Same reason.
>
> > int total_vports;
> > int enabled_vports;
> > /* Synchronize between vport change events @@ -240,6 +247,8 @@
> > void esw_vport_disable_egress_acl(struct mlx5_eswitch *esw,
> > struct mlx5_vport *vport);
> > void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw,
> > struct mlx5_vport *vport);
> > +void esw_vport_del_ingress_acl_modify_metadata(struct mlx5_eswitch *esw,
> > + struct mlx5_vport *vport);
> >
> > /* E-Switch API */
> > int mlx5_eswitch_init(struct mlx5_core_dev *dev); diff --git
> > a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > index 17abb98b48af..871ae44dc132 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
...
> > +static int esw_create_offloads_acl_tables(struct mlx5_eswitch *esw) {
> > + struct mlx5_vport *vport;
> > + int i, j;
> > + int err;
> > +
> > + mlx5_esw_for_all_vports(esw, i, vport) {
> > + err = esw_vport_ingress_common_config(esw, vport);
> > if (err)
> > - goto err_egress;
> > + goto err_ingress;
> > +
> > + if (vport->vport >= MLX5_VPORT_FIRST_VF &&
> > + vport->vport <= esw->dev->priv.sriov.num_vfs) {
> Add an helper API mlx5_esw_is_vport(const struct mlx5_esw *esw, const struct mlx5_vport *vport)
> and use at two places in ingress and egress config.
It's very simple logic, but new API make things complicated. If adding
mlx5_esw_is_vport() as you suggested, no one can know what's the meaning
of this function from name, and need to check the implementation again,
which will waste too much time.
>
^ permalink raw reply
* RE: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
From: Martin Blumenstingl @ 2019-06-19 5:13 UTC (permalink / raw)
To: colin.king
Cc: alexandre.torgue, davem, joabreu, kernel-janitors,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, peppe.cavallaro
In-Reply-To: <20190617165836.4673-1-colin.king@canonical.com>
Hi Colin,
> Currently the call to device_property_read_u32_array is not error checked
> leading to potential garbage values in the delays array that are then used
> in msleep delays. Add a sanity check to the property fetching.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
I have also sent a patch [0] to fix initialize the array.
can you please look at my patch so we can work out which one to use?
my concern is that the "snps,reset-delays-us" property is optional,
the current dt-bindings documentation states that it's a required
property. in reality it isn't, there are boards (two examples are
mentioned in my patch: [0]) without it.
so I believe that the resulting behavior has to be:
1. don't delay if this property is missing (instead of delaying for
<garbage value> ms)
2. don't error out if this property is missing
your patch covers #1, can you please check whether #2 is also covered?
I tested case #2 when submitting my patch and it worked fine (even
though I could not reproduce the garbage values which are being read
on some boards)
Thank you!
Martin
[0] https://lkml.org/lkml/2019/4/19/638
^ permalink raw reply
* [net-next:master 91/276] ERROR: "nf_ct_frag6_gather" [net/ipv6/ipv6.ko] undefined!
From: kbuild test robot @ 2019-06-19 5:12 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: kbuild-all, netdev, wenxu
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 39f5886032380e49119786b23274b38e9b3aa99c
commit: c9bb6165a16e6d5498981a6c777b94a78e74462b [91/276] netfilter: nf_conntrack_bridge: fix CONFIG_IPV6=y
config: i386-randconfig-n027-201924 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
git checkout c9bb6165a16e6d5498981a6c777b94a78e74462b
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> ERROR: "nf_ct_frag6_gather" [net/ipv6/ipv6.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33110 bytes --]
^ permalink raw reply
* Re: [PATCH] mm: mempolicy: handle vma with unmovable pages mapped correctly in mbind
From: Michal Hocko @ 2019-06-19 5:21 UTC (permalink / raw)
To: Yang Shi
Cc: akpm, vbabka, mgorman, linux-mm, linux-kernel, Eric Dumazet,
David S. Miller, netdev
In-Reply-To: <68c2592d-b747-e6eb-329f-7a428bff1f86@linux.alibaba.com>
On Tue 18-06-19 14:13:16, Yang Shi wrote:
[...]
> > > > > Change migrate_page_add() to check if the page is movable or not, if it
> > > > > is unmovable, just return -EIO. We don't have to check non-LRU movable
> > > > > pages since just zsmalloc and virtio-baloon support this. And, they
> > > > > should be not able to reach here.
> > > > You are not checking whether the page is movable, right? You only rely
> > > > on PageLRU check which is not really an equivalent thing. There are
> > > > movable pages which are not LRU and also pages might be off LRU
> > > > temporarily for many reasons so this could lead to false positives.
> > > I'm supposed non-LRU movable pages could not reach here. Since most of them
> > > are not mmapable, i.e. virtio-balloon, zsmalloc. zram device is mmapable,
> > > but the page fault to that vma would end up allocating user space pages
> > > which are on LRU. If I miss something please let me know.
> > That might be true right now but it is a very subtle assumption that
> > might break easily in the future. The point is still that even LRU pages
> > might be isolated from the LRU list temporarily and you do not want this
> > to cause the failure easily.
>
> I used to have !__PageMovable(page), but it was removed since the
> aforementioned reason. I could add it back.
>
> For the temporary off LRU page, I did a quick search, it looks the most
> paths have to acquire mmap_sem, so it can't race with us here. Page
> reclaim/compaction looks like the only race. But, since the mapping should
> be preserved even though the page is off LRU temporarily unless the page is
> reclaimed, so we should be able to exclude temporary off LRU pages by
> calling page_mapping() and page_anon_vma().
>
> So, the fix may look like:
>
> if (!PageLRU(head) && !__PageMovable(page)) {
> if (!(page_mapping(page) || page_anon_vma(page)))
> return -EIO;
This is getting even more muddy TBH. Is there any reason that we have to
handle this problem during the isolation phase rather the migration?
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* RE: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with vport number in VF vports and uplink ingress ACLs
From: Parav Pandit @ 2019-06-19 5:42 UTC (permalink / raw)
To: Jianbo Liu
Cc: Saeed Mahameed, Leon Romanovsky, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Eli Britstein, Roi Dayan, Mark Bloch
In-Reply-To: <20190619051143.GB30694@mellanox.com>
> -----Original Message-----
> From: Jianbo Liu
> Sent: Wednesday, June 19, 2019 10:42 AM
> To: Parav Pandit <parav@mellanox.com>
> Cc: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> <leonro@mellanox.com>; netdev@vger.kernel.org; linux-
> rdma@vger.kernel.org; Eli Britstein <elibr@mellanox.com>; Roi Dayan
> <roid@mellanox.com>; Mark Bloch <markb@mellanox.com>
> Subject: Re: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with
> vport number in VF vports and uplink ingress ACLs
>
> The 06/18/2019 18:31, Parav Pandit wrote:
> >
> >
> > > -----Original Message-----
> > > From: netdev-owner@vger.kernel.org <netdev-owner@vger.kernel.org> On
> > > Behalf Of Saeed Mahameed
> > > Sent: Tuesday, June 18, 2019 12:53 AM
> > > To: Saeed Mahameed <saeedm@mellanox.com>; Leon Romanovsky
> > > <leonro@mellanox.com>
> > > Cc: netdev@vger.kernel.org; linux-rdma@vger.kernel.org; Jianbo Liu
> > > <jianbol@mellanox.com>; Eli Britstein <elibr@mellanox.com>; Roi
> > > Dayan <roid@mellanox.com>; Mark Bloch <markb@mellanox.com>
> > > Subject: [PATCH mlx5-next 05/15] net/mlx5: E-Switch, Tag packet with
> > > vport number in VF vports and uplink ingress ACLs
> > >
> > > From: Jianbo Liu <jianbol@mellanox.com>
> > >
> > > When a dual-port VHCA sends a RoCE packet on its non-native port,
> > > and the packet arrives to its affiliated vport FDB, a mismatch might
> > > occur on the rules that match the packet source vport as it is not
> > > represented by single VHCA only in this case. So we change to match on
> metadata instead of source vport.
> > > To do that, a rule is created in all vports and uplink ingress ACLs,
> > > to save the source vport number and vhca id in the packet's metadata
> > > in order to match on it later.
> > > The metadata register used is the first of the 32-bit type C
> > > registers. It can be used for matching and header modify operations.
> > > The higher 16 bits of this register are for vhca id, and the lower 16 ones is
> for vport number.
> > > This change is not for dual-port RoCE only. If HW and FW allow, the
> > > vport metadata matching is enabled by default.
> > >
> > > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > > Reviewed-by: Eli Britstein <elibr@mellanox.com>
> > > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > > ---
> > > .../net/ethernet/mellanox/mlx5/core/eswitch.c | 2 +
> > > .../net/ethernet/mellanox/mlx5/core/eswitch.h | 9 +
> > > .../mellanox/mlx5/core/eswitch_offloads.c | 183 ++++++++++++++----
> > > include/linux/mlx5/eswitch.h | 3 +
> > > 4 files changed, 161 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > > index a42a23e505df..1235fd84ae3a 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.c
> > > @@ -1168,6 +1168,8 @@ void esw_vport_cleanup_ingress_rules(struct
> > > mlx5_eswitch *esw,
> > >
> > > vport->ingress.drop_rule = NULL;
> > > vport->ingress.allow_rule = NULL;
> > > +
> > > + esw_vport_del_ingress_acl_modify_metadata(esw, vport);
> > > }
> > >
> > > void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw, diff
> > > --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > > index 8b9f2cf58e91..4417a195832e 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch.h
> > > @@ -68,6 +68,8 @@ struct vport_ingress {
> > > struct mlx5_flow_group *allow_spoofchk_only_grp;
> > > struct mlx5_flow_group *allow_untagged_only_grp;
> > > struct mlx5_flow_group *drop_grp;
> > > + int modify_metadata_id;
> > No need for random alignment. Just have one white space after int.
>
> Not random. It's to align with other lines in the this structure.
> There are also other fileds with more than one spaces after type.
> It looks ugly if there are different styles in the same structure.
>
Whatever was done in past was done.
There will be mixed alignment anyway.
> >
> > > + struct mlx5_flow_handle *modify_metadata_rule;
> > > struct mlx5_flow_handle *allow_rule;
> > > struct mlx5_flow_handle *drop_rule;
> > > struct mlx5_fc *drop_counter;
> > > @@ -196,6 +198,10 @@ struct mlx5_esw_functions {
> > > u16 num_vfs;
> > > };
> > >
> > > +enum {
> > > + MLX5_ESWITCH_VPORT_MATCH_METADATA = BIT(0), };
> > > +
> > > struct mlx5_eswitch {
> > > struct mlx5_core_dev *dev;
> > > struct mlx5_nb nb;
> > > @@ -203,6 +209,7 @@ struct mlx5_eswitch {
> > > struct hlist_head mc_table[MLX5_L2_ADDR_HASH_SIZE];
> > > struct workqueue_struct *work_queue;
> > > struct mlx5_vport *vports;
> > > + u32 flags;
> > Same as above, no need for extra aligment.
>
> Same reason.
>
> >
> > > int total_vports;
> > > int enabled_vports;
> > > /* Synchronize between vport change events @@ -240,6 +247,8 @@
> > > void esw_vport_disable_egress_acl(struct mlx5_eswitch *esw,
> > > struct mlx5_vport *vport);
> > > void esw_vport_disable_ingress_acl(struct mlx5_eswitch *esw,
> > > struct mlx5_vport *vport);
> > > +void esw_vport_del_ingress_acl_modify_metadata(struct mlx5_eswitch
> *esw,
> > > + struct mlx5_vport *vport);
> > >
> > > /* E-Switch API */
> > > int mlx5_eswitch_init(struct mlx5_core_dev *dev); diff --git
> > > a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > > b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > > index 17abb98b48af..871ae44dc132 100644
> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>
> ...
>
> > > +static int esw_create_offloads_acl_tables(struct mlx5_eswitch *esw) {
> > > + struct mlx5_vport *vport;
> > > + int i, j;
> > > + int err;
> > > +
> > > + mlx5_esw_for_all_vports(esw, i, vport) {
> > > + err = esw_vport_ingress_common_config(esw, vport);
> > > if (err)
> > > - goto err_egress;
> > > + goto err_ingress;
> > > +
> > > + if (vport->vport >= MLX5_VPORT_FIRST_VF &&
> > > + vport->vport <= esw->dev->priv.sriov.num_vfs) {
> > Add an helper API mlx5_esw_is_vport(const struct mlx5_esw *esw, const
> > struct mlx5_vport *vport) and use at two places in ingress and egress config.
>
> It's very simple logic, but new API make things complicated.
No. it doesn't. Right API name is,
mlx5_esw_is_vf_vport().
mlx5_esw_is_vf_rep()...
etc.
> If adding mlx5_esw_is_vport() as you suggested, no one can know what's the meaning of
> this function from name, and need to check the implementation again, which
> will waste too much time.
>
mlx5_esw_is_vf_vport() is self-explanatory name which won't waste time.
I am already having this API in my two series, but since yours is already out, it make sense to introduce in this patch.
^ permalink raw reply
* RE: [PATCH v2 6/6] net: macb: parameter added to cadence ethernet controller DT binding
From: Parshuram Raju Thombare @ 2019-06-19 6:08 UTC (permalink / raw)
To: Florian Fainelli, andrew@lunn.ch, nicolas.ferre@microchip.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org, hkallweit1@gmail.com,
linux-kernel@vger.kernel.org, Rafal Ciepiela, Anil Joy Varughese,
Piotr Sroka
In-Reply-To: <0375c350-ed33-728d-4106-e6f5348c5295@gmail.com>
Hi Florian,
>Please don't resubmit individual patches as replies to your previous
>ones, re-submitting the entire patch series, see this netdev-FAQ section
>for details:
I will resubmit entire patch series separately.
>
>> +- serdes-rate External serdes rate.Mandatory for USXGMII mode.
>
>> + 5 - 5G
>
>> + 10 - 10G
>
>
>
>There should be an unit specifier in that property, something like:
>serdes-rate-gbps
>can't we somehow automatically detect that?
Ok, sure. I will add unit specifier to property name.
No, currently HW don’t have way to auto detect external serdes rate.
Regards,
Parshuram Thombare
^ permalink raw reply
* [net v1] net: stmmac: fixed new system time seconds value calculation
From: Voon Weifeng @ 2019-06-19 14:13 UTC (permalink / raw)
To: David S. Miller, Maxime Coquelin
Cc: netdev, linux-kernel, Jose Abreu, Giuseppe Cavallaro, Andrew Lunn,
Florian Fainelli, Alexandre Torgue, Ong Boon Leong, Voon Weifeng
From: Roland Hii <roland.king.guan.hii@intel.com>
When ADDSUB bit is set, the system time seconds field is calculated as
the complement of the seconds part of the update value.
For example, if 3.000000001 seconds need to be subtracted from the
system time, this field is calculated as
2^32 - 3 = 4294967296 - 3 = 0x100000000 - 3 = 0xFFFFFFFD
Previously, the 0x100000000 is mistakenly written as 100000000.
This is further simplified from
sec = (0x100000000ULL - sec);
to
sec = -sec;
Fixes: ba1ffd74df74 ("stmmac: fix PTP support for GMAC4")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 2dcdf761d525..020159622559 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -112,7 +112,7 @@ static int adjust_systime(void __iomem *ioaddr, u32 sec, u32 nsec,
* programmed with (2^32 – <new_sec_value>)
*/
if (gmac4)
- sec = (100000000ULL - sec);
+ sec = -sec;
value = readl(ioaddr + PTP_TCR);
if (value & PTP_TCR_TSCTRLSSR)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH mlx5-next 11/15] RDMA/mlx5: Add vport metadata matching for IB representors
From: Jianbo Liu @ 2019-06-19 6:40 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Saeed Mahameed, netdev@vger.kernel.org,
linux-rdma@vger.kernel.org, Roi Dayan, Mark Bloch
In-Reply-To: <20190619050412.GC11611@mtr-leonro.mtl.com>
The 06/19/2019 13:04, Leon Romanovsky wrote:
> On Wed, Jun 19, 2019 at 04:44:26AM +0000, Jianbo Liu wrote:
> > The 06/18/2019 18:19, Leon Romanovsky wrote:
> > > On Mon, Jun 17, 2019 at 07:23:30PM +0000, Saeed Mahameed wrote:
> > > > From: Jianbo Liu <jianbol@mellanox.com>
> > > >
> > > > If vport metadata matching is enabled in eswitch, the rule created
> > > > must be changed to match on the metadata, instead of source port.
> > > >
> > > > Signed-off-by: Jianbo Liu <jianbol@mellanox.com>
> > > > Reviewed-by: Roi Dayan <roid@mellanox.com>
> > > > Reviewed-by: Mark Bloch <markb@mellanox.com>
> > > > Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
> > > > ---
> > > > drivers/infiniband/hw/mlx5/ib_rep.c | 11 +++++++
> > > > drivers/infiniband/hw/mlx5/ib_rep.h | 16 ++++++++++
> > > > drivers/infiniband/hw/mlx5/main.c | 45 +++++++++++++++++++++++------
> > > > 3 files changed, 63 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c b/drivers/infiniband/hw/mlx5/ib_rep.c
> > > > index 22e651cb5534..d4ed611de35d 100644
> > > > --- a/drivers/infiniband/hw/mlx5/ib_rep.c
> > > > +++ b/drivers/infiniband/hw/mlx5/ib_rep.c
> > > > @@ -131,6 +131,17 @@ struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw, int vport)
> > > > return mlx5_eswitch_vport_rep(esw, vport);
> > > > }
> > > >
> > > > +u32 mlx5_ib_eswitch_vport_match_metadata_enabled(struct mlx5_eswitch *esw)
> > > > +{
> > > > + return mlx5_eswitch_vport_match_metadata_enabled(esw);
> > > > +}
> > > > +
> > > > +u32 mlx5_ib_eswitch_get_vport_metadata_for_match(struct mlx5_eswitch *esw,
> > > > + u16 vport)
> > > > +{
> > > > + return mlx5_eswitch_get_vport_metadata_for_match(esw, vport);
> > > > +}
> > >
> > > 1. There is no need to introduce one line functions, call to that code directly.
> >
> > No. They are in IB, and we don't want them be mixed up by the original
> > functions in eswitch. Please ask Mark more about it.
>
> Please enlighten me.
It was suggested by Mark in prevouis review.
I think it's because there are in different modules, and better to with
different names, so introduce there extra one line functions.
Please correct me if I'm wrong, Mark...
>
> >
> > > 2. It should be bool and not u32.
> > >
> > > Thanks
> >
> > --
--
^ permalink raw reply
* Re: [PATCH] [v2] ipsec: select crypto ciphers for xfrm_algo
From: Herbert Xu @ 2019-06-19 6:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Steffen Klassert, David S. Miller, Florian Westphal, netdev,
linux-kernel
In-Reply-To: <20190618112227.3322313-1-arnd@arndb.de>
On Tue, Jun 18, 2019 at 01:22:13PM +0200, Arnd Bergmann wrote:
> kernelci.org reports failed builds on arc because of what looks
> like an old missed 'select' statement:
>
> net/xfrm/xfrm_algo.o: In function `xfrm_probe_algs':
> xfrm_algo.c:(.text+0x1e8): undefined reference to `crypto_has_ahash'
>
> I don't see this in randconfig builds on other architectures, but
> it's fairly clear we want to select the hash code for it, like we
> do for all its other users. As Herbert points out, CRYPTO_BLKCIPHER
> is also required even though it has not popped up in build tests.
>
> Fixes: 17bc19702221 ("ipsec: Use skcipher and ahash when probing algorithms")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> net/xfrm/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [net v1] net: stmmac: set IC bit when transmitting frames with HW timestamp
From: Voon Weifeng @ 2019-06-19 14:41 UTC (permalink / raw)
To: David S. Miller, Maxime Coquelin
Cc: netdev, linux-kernel, Jose Abreu, Giuseppe Cavallaro, Andrew Lunn,
Florian Fainelli, Alexandre Torgue, Ong Boon Leong, Voon Weifeng
From: Roland Hii <roland.king.guan.hii@intel.com>
When transmitting certain PTP frames, e.g. SYNC and DELAY_REQ, the
PTP daemon, e.g. ptp4l, is polling the driver for the frame transmit
hardware timestamp. The polling will most likely timeout if the tx
coalesce is enabled due to the Interrupt-on-Completion (IC) bit is
not set in tx descriptor for those frames.
This patch will ignore the tx coalesce parameter and set the IC bit
when transmitting PTP frames which need to report out the frame
transmit hardware timestamp to user space.
Fixes: f748be531d70 ("net: stmmac: Rework coalesce timer and fix multi-queue races")
Signed-off-by: Roland Hii <roland.king.guan.hii@intel.com>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 06dd51f47cfd..06358fe5b245 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2947,12 +2947,15 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev)
/* Manage tx mitigation */
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
@@ -3166,12 +3169,15 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev)
* element in case of no SG.
*/
tx_q->tx_count_frames += nfrags + 1;
- if (priv->tx_coal_frames <= tx_q->tx_count_frames) {
+ if (likely(priv->tx_coal_frames > tx_q->tx_count_frames) &&
+ !(priv->synopsys_id >= DWMAC_CORE_4_00 &&
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) &&
+ priv->hwts_tx_en)) {
+ stmmac_tx_timer_arm(priv, queue);
+ } else {
+ tx_q->tx_count_frames = 0;
stmmac_set_tx_ic(priv, desc);
priv->xstats.tx_set_ic_bit++;
- tx_q->tx_count_frames = 0;
- } else {
- stmmac_tx_timer_arm(priv, queue);
}
skb_tx_timestamp(skb);
--
1.9.1
^ 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