* Re: [PATCH net-next] bpfilter: fix a build err
From: David Miller @ 2018-05-29 19:20 UTC (permalink / raw)
To: yuehaibing; +Cc: ast, netdev, linux-kernel
In-Reply-To: <20180525101757.13756-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Fri, 25 May 2018 18:17:57 +0800
> gcc-7.3.0 report following err:
>
> HOSTCC net/bpfilter/main.o
> In file included from net/bpfilter/main.c:9:0:
> ./include/uapi/linux/bpf.h:12:10: fatal error: linux/bpf_common.h: No such file or directory
> #include <linux/bpf_common.h>
>
> remove it by adding a include path.
> Fixes: d2ba09c17a06 ("net: add skeleton of bpfilter kernel module")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/4 RFCv2] net: dsa: Add bindings for Realtek SMI DSAs
From: Florian Fainelli @ 2018-05-29 19:30 UTC (permalink / raw)
To: Linus Walleij, Andrew Lunn, Vivien Didelot
Cc: netdev, openwrt-devel, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos, devicetree
In-Reply-To: <20180528174752.6806-3-linus.walleij@linaro.org>
On 05/28/2018 10:47 AM, Linus Walleij wrote:
> The Realtek SMI family is a set of DSA chips that provide
> switching in routers. This binding just follows the pattern
> set by other switches but with the introduction of an embedded
> irqchip to demux and handle the interrupts fired by the single
> line from the chip.
>
> This interrupt construction is similar to how we handle
> interrupt controllers inside PCI bridges etc.
>
> Cc: Antti Seppälä <a.seppala@gmail.com>
> Cc: Roman Yeryomin <roman@advem.lv>
> Cc: Colin Leitner <colin.leitner@googlemail.com>
> Cc: Gabor Juhos <juhosg@openwrt.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> +
> + mdio {
> + compatible = "realtek,smi-mdio", "dsa-mdio";
You should drop the "dsa-mdio" compatible string here since it both non
documented and not matched either.
Other than that, this looks great, with that fixed:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* RE: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Ruhl, Michael J @ 2018-05-29 19:31 UTC (permalink / raw)
To: Leon Romanovsky, Doug Ledford, Jason Gunthorpe
Cc: Leon Romanovsky, RDMA mailing list, Boris Pismenny, Matan Barak,
Raed Salem, Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <20180529130917.13592-2-leon@kernel.org>
>-----Original Message-----
>From: linux-rdma-owner@vger.kernel.org [mailto:linux-rdma-
>owner@vger.kernel.org] On Behalf Of Leon Romanovsky
>Sent: Tuesday, May 29, 2018 9:09 AM
>To: Doug Ledford <dledford@redhat.com>; Jason Gunthorpe
><jgg@mellanox.com>
>Cc: Leon Romanovsky <leonro@mellanox.com>; RDMA mailing list <linux-
>rdma@vger.kernel.org>; Boris Pismenny <borisp@mellanox.com>; Matan
>Barak <matanb@mellanox.com>; Raed Salem <raeds@mellanox.com>; Yishai
>Hadas <yishaih@mellanox.com>; Saeed Mahameed
><saeedm@mellanox.com>; linux-netdev <netdev@vger.kernel.org>
>Subject: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to
>ioctl() infrastructure
>
>From: Matan Barak <matanb@mellanox.com>
>
>Previously, the user had to dig inside the attribute to get the uobject.
>Add a helper function that correctly extract it (and do the required
>checks) for him/her.
>
>Tested-by: Michael Guralnik <michaelgur@mellanox.com>
>Signed-off-by: Matan Barak <matanb@mellanox.com>
>Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>---
> drivers/infiniband/core/uverbs_std_types_cq.c | 23 +++++++++++---------
>--
> .../infiniband/core/uverbs_std_types_flow_action.c | 4 ++--
> include/rdma/uverbs_ioctl.h | 11 +++++++++++
> 3 files changed, 25 insertions(+), 13 deletions(-)
>
>diff --git a/drivers/infiniband/core/uverbs_std_types_cq.c
>b/drivers/infiniband/core/uverbs_std_types_cq.c
>index b0dbae9dd0d7..3d293d01afea 100644
>--- a/drivers/infiniband/core/uverbs_std_types_cq.c
>+++ b/drivers/infiniband/core/uverbs_std_types_cq.c
>@@ -65,7 +65,6 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_CQ_CREATE)(struct ib_device *ib_dev,
> struct ib_cq_init_attr attr = {};
> struct ib_cq *cq;
> struct ib_uverbs_completion_event_file *ev_file = NULL;
>- const struct uverbs_attr *ev_file_attr;
> struct ib_uobject *ev_file_uobj;
>
> if (!(ib_dev->uverbs_cmd_mask & 1ULL <<
>IB_USER_VERBS_CMD_CREATE_CQ))
>@@ -87,10 +86,8 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_CQ_CREATE)(struct ib_device *ib_dev,
>
> UVERBS_ATTR_CREATE_CQ_FLAGS)))
> return -EFAULT;
>
>- ev_file_attr = uverbs_attr_get(attrs,
>UVERBS_ATTR_CREATE_CQ_COMP_CHANNEL);
>- if (!IS_ERR(ev_file_attr)) {
>- ev_file_uobj = ev_file_attr->obj_attr.uobject;
>-
>+ ev_file_uobj = uverbs_attr_get_uobject(attrs,
>UVERBS_ATTR_CREATE_CQ_COMP_CHANNEL);
>+ if (!IS_ERR(ev_file_uobj)) {
> ev_file = container_of(ev_file_uobj,
> struct ib_uverbs_completion_event_file,
> uobj_file.uobj);
>@@ -102,8 +99,8 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_CQ_CREATE)(struct ib_device *ib_dev,
> goto err_event_file;
> }
>
>- obj = container_of(uverbs_attr_get(attrs,
>-
>UVERBS_ATTR_CREATE_CQ_HANDLE)->obj_attr.uobject,
See comment below on error checking. Does this need the error check?
>+ obj = container_of(uverbs_attr_get_uobject(attrs,
>+
>UVERBS_ATTR_CREATE_CQ_HANDLE),
> typeof(*obj), uobject);
> obj->uverbs_file = ucontext->ufile;
> obj->comp_events_reported = 0;
>@@ -170,13 +167,17 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_CQ_DESTROY)(struct ib_device
>*ib_dev,
> struct ib_uverbs_file *file,
> struct uverbs_attr_bundle
>*attrs)
> {
>- struct ib_uverbs_destroy_cq_resp resp;
> struct ib_uobject *uobj =
>- uverbs_attr_get(attrs,
>UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
>- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
>- uobject);
>+ uverbs_attr_get_uobject(attrs,
>UVERBS_ATTR_DESTROY_CQ_HANDLE);
>+ struct ib_uverbs_destroy_cq_resp resp;
>+ struct ib_ucq_object *obj;
> int ret;
>
>+ if (IS_ERR(uobj))
>+ return PTR_ERR(uobj);
>+
I remember a conversation that if an method attribute was mandatory, that you did not need to
test the uobj for error (since it was checked in the infrastructure).
Is this error check necessary?
Thanks
Mike
>+ obj = container_of(uobj, struct ib_ucq_object, uobject);
>+
> if (!(ib_dev->uverbs_cmd_mask & 1ULL <<
>IB_USER_VERBS_CMD_DESTROY_CQ))
> return -EOPNOTSUPP;
>
>diff --git a/drivers/infiniband/core/uverbs_std_types_flow_action.c
>b/drivers/infiniband/core/uverbs_std_types_flow_action.c
>index b4f016dfa23d..a7be51cf2e42 100644
>--- a/drivers/infiniband/core/uverbs_std_types_flow_action.c
>+++ b/drivers/infiniband/core/uverbs_std_types_flow_action.c
>@@ -320,7 +320,7 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_CREATE)(struct
>ib_device
> return ret;
>
> /* No need to check as this attribute is marked as MANDATORY */
>- uobj = uverbs_attr_get(attrs,
>UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
>+ uobj = uverbs_attr_get_uobject(attrs,
>UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
> action = ib_dev->create_flow_action_esp(ib_dev, &esp_attr.hdr,
>attrs);
> if (IS_ERR(action))
> return PTR_ERR(action);
>@@ -350,7 +350,7 @@ static int
>UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_MODIFY)(struct
>ib_device
> if (ret)
> return ret;
>
>- uobj = uverbs_attr_get(attrs,
>UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
>+ uobj = uverbs_attr_get_uobject(attrs,
>UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
> action = uobj->object;
>
> if (action->type != IB_FLOW_ACTION_ESP)
>diff --git a/include/rdma/uverbs_ioctl.h b/include/rdma/uverbs_ioctl.h
>index 4a4201d997a7..7ac6271a5ee0 100644
>--- a/include/rdma/uverbs_ioctl.h
>+++ b/include/rdma/uverbs_ioctl.h
>@@ -420,6 +420,17 @@ static inline void *uverbs_attr_get_obj(const struct
>uverbs_attr_bundle *attrs_b
> return uobj->object;
> }
>
>+static inline struct ib_uobject *uverbs_attr_get_uobject(const struct
>uverbs_attr_bundle *attrs_bundle,
>+ u16 idx)
>+{
>+ const struct uverbs_attr *attr = uverbs_attr_get(attrs_bundle, idx);
>+
>+ if (IS_ERR(attr))
>+ return ERR_CAST(attr);
>+
>+ return attr->obj_attr.uobject;
>+}
>+
> static inline int uverbs_copy_to(const struct uverbs_attr_bundle
>*attrs_bundle,
> size_t idx, const void *from, size_t size)
> {
>--
>2.14.3
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: clean up eBPF helpers documentation
From: Daniel Borkmann @ 2018-05-29 19:44 UTC (permalink / raw)
To: Song Liu, Quentin Monnet; +Cc: Alexei Starovoitov, Networking, oss-drivers
In-Reply-To: <CAPhsuW4Oi5P=Mbxn1=b5XWiBptd6-SG7dLuEpmCe10G3Cufj6A@mail.gmail.com>
On 05/29/2018 08:27 PM, Song Liu wrote:
> On Tue, May 29, 2018 at 4:27 AM, Quentin Monnet
> <quentin.monnet@netronome.com> wrote:
>> These are minor edits for the eBPF helpers documentation in
>> include/uapi/linux/bpf.h.
>>
>> The main fix consists in removing "BPF_FIB_LOOKUP_", because it ends
>> with a non-escaped underscore that gets interpreted by rst2man and
>> produces the following message in the resulting manual page:
>>
>> DOCUTILS SYSTEM MESSAGES
>> System Message: ERROR/3 (/tmp/bpf-helpers.rst:, line 1514)
>> Unknown target name: "bpf_fib_lookup".
>>
>> Other edits consist in:
>>
>> - Improving formatting for flag values for "bpf_fib_lookup()" helper.
>> - Emphasising a parameter name in description of the return value for
>> "bpf_get_stack()" helper.
>> - Removing unnecessary blank lines between "Description" and "Return"
>> sections for the few helpers that would use it, for consistency.
>>
>> Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
[...]
>
> Please also apply the same changes to tools/include/uapi/linux/bpf.h.
Just did while applying to bpf-next, thanks guys!
> Other than this, it looks to me.
>
> Acked-by: Song Liu <songliubraving@fb.com>
>
> Thanks,
> Song
>
^ permalink raw reply
* Re: [OpenWrt-Devel] [PATCH 0/4 RFCv2] Realtek SMI RTL836x DSA driver
From: Linus Walleij @ 2018-05-29 19:47 UTC (permalink / raw)
To: Kevin Darbyshire-Bryant
Cc: Andrew Lunn, netdev, Florian Fainelli, LEDE Development List,
Vivien Didelot
In-Reply-To: <6FB2D569-87D4-47A9-AB6D-51B85720B6DA@darbyshire-bryant.me.uk>
On Tue, May 29, 2018 at 8:57 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
> Oh lordy, that horrible device as exhibited in the netgear DGN3500. Talk about magic values
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=42120bd7f323ff7170b32a5fd4674babd8b184bc
Yeah I even copied that init sequence over to this driver, however
I actually think I have the LED activity somewhat under control in
this new driver as those registers were kind-of-sort-of documented
in the vendor code drop.
It turns out the D-Link thing I am playing with doesn't even have
any LEDs mounted so I can't test it though.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: hide the unused 'off' variable
From: Daniel Borkmann @ 2018-05-29 19:50 UTC (permalink / raw)
To: Song Liu, John Fastabend
Cc: Arnd Bergmann, YueHaibing, David Miller, Alexei Starovoitov,
Networking, Linux Kernel Mailing List
In-Reply-To: <CAPhsuW7tkQVY0rVRt2=cAHf_fif7W_73Ns7_mnt3CriMbGEhrg@mail.gmail.com>
On 05/29/2018 08:18 PM, Song Liu wrote:
> On Tue, May 29, 2018 at 8:53 AM, John Fastabend
> <john.fastabend@gmail.com> wrote:
>> On 05/29/2018 03:35 AM, Arnd Bergmann wrote:
>>> On Tue, May 29, 2018 at 4:40 AM, YueHaibing <yuehaibing@huawei.com> wrote:
>>>> The local variable is only used while CONFIG_IPV6 enabled
>>>>
>>>> net/core/filter.c: In function ‘sk_msg_convert_ctx_access’:
>>>> net/core/filter.c:6489:6: warning: unused variable ‘off’ [-Wunused-variable]
>>>> int off;
>>>> ^
>>>> This puts it into #ifdef.
>>>>
>>>> Fixes: 303def35f64e ("bpf: allow sk_msg programs to read sock fields")
>>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>>
>>> I was about to send the same patch and found you had already sent one.
>>>
>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>
>> Thanks! I'm curious why kbuild bot didn't catch this. Will
>> try to dig into that in a bit.
>>
>> Acked-by: John Fastabend <john.fastabend@gmail.com>
>
> Acked-by: Song Liu <songliubraving@fb.com>
Applied to bpf-next, thanks Yue!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Verify flags in bpf_fib_lookup
From: Daniel Borkmann @ 2018-05-29 19:51 UTC (permalink / raw)
To: dsahern, netdev, borkmann, ast; +Cc: David Ahern
In-Reply-To: <20180529185913.11697-1-dsahern@kernel.org>
On 05/29/2018 08:59 PM, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> Verify flags argument contains only known flags. Allows programs to probe
> for support as more are added.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied to bpf-next, thanks David!
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: Drop mpls from bpf_fib_lookup
From: Daniel Borkmann @ 2018-05-29 19:51 UTC (permalink / raw)
To: dsahern, netdev, borkmann, ast; +Cc: David Ahern
In-Reply-To: <20180529175807.20734-1-dsahern@kernel.org>
On 05/29/2018 07:58 PM, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> MPLS support will not be submitted this dev cycle, but in working on it
> I do see a few changes are needed to the API. For now, drop mpls from the
> API. Since the fields in question are unions, the mpls fields can be added
> back later without affecting the uapi.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied to bpf-next, thanks David!
^ permalink raw reply
* Re: [PATCH bpf-next 04/11] bpf: show prog and map id in fdinfo
From: Daniel Borkmann @ 2018-05-29 19:55 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev
In-Reply-To: <20180529192758.28240588@redhat.com>
On 05/29/2018 07:27 PM, Jesper Dangaard Brouer wrote:
> On Mon, 28 May 2018 02:43:37 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> Its trivial and straight forward to expose it for scripts that can
>> then use it along with bpftool in order to inspect an individual
>> application's used maps and progs. Right now we dump some basic
>> information in the fdinfo file but with the help of the map/prog
>> id full introspection becomes possible now.
>>
>> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
>> Acked-by: Alexei Starovoitov <ast@kernel.org>
>
> AFAICR iproute uses this proc fdinfo, for pinned maps. Have you tested
> if this change is handled gracefully by tc ?
Yep, it works just fine, I also tested it before submission.
^ permalink raw reply
* Re: [PATCH mlx5-next v2 11/13] IB/mlx5: Add flow counters binding support
From: Jason Gunthorpe @ 2018-05-29 19:56 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Boris Pismenny,
Matan Barak, Raed Salem, Yishai Hadas, Saeed Mahameed,
linux-netdev, Alex Rosenbaum
In-Reply-To: <20180529130917.13592-12-leon@kernel.org>
On Tue, May 29, 2018 at 04:09:15PM +0300, Leon Romanovsky wrote:
> diff --git a/include/uapi/rdma/mlx5-abi.h b/include/uapi/rdma/mlx5-abi.h
> index 508ea8c82da7..ef3f430a7050 100644
> +++ b/include/uapi/rdma/mlx5-abi.h
> @@ -443,4 +443,18 @@ enum {
> enum {
> MLX5_IB_CLOCK_INFO_V1 = 0,
> };
> +
> +struct mlx5_ib_flow_counters_data {
> + __aligned_u64 counters_data;
> + __u32 ncounters;
> + __u32 reserved;
> +};
> +
> +struct mlx5_ib_create_flow {
> + __u32 ncounters_data;
> + __u32 reserved;
> + /* Following are counters data based on ncounters_data */
> + struct mlx5_ib_flow_counters_data data[];
> +};
> +
> #endif /* MLX5_ABI_USER_H */
This uapi thing still needs to be fixed as I pointed out before.
I still can't figure out why this should be a 2d array. I think it
should be written simply as:
struct mlx5_ib_flow_counter_desc {
__u32 description;
__u32 index;
};
struct mlx5_ib_create_flow {
RDMA_UAPI_PTR(struct mlx5_ib_flow_counter_desc, counters_data);
__u32 ncounters;
__u32 reserved;
};
With the corresponding changes elsewhere.
A flex array at the end of a struct means that the struct can never be
extended again which seems like a terrible idea, especially since I
can't fathom why we'd need more that one array of counters and the
current code doesn't even support more than one..
Jason
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Linus Walleij @ 2018-05-29 20:01 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <a69f23bf-cc3d-195b-03f9-17b2b9aa180b@gmail.com>
On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> +#define RTL8366RB_POWER_SAVE 0x21
> Typically PHY register addresses are 5 bits wide, is 0x21 correct
> and I miss something?
If it is correct I don't know, but it appears in the vendor
code:
/*Power Saving*/
#define RTL8368S_POWER_SAVING_PAGE 0
#define RTL8368S_POWER_SAVING_REG 21
#define RTL8368S_POWER_SAVING_BIT_MSK 0x1000
Then:
phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |
((RTL8368S_POWER_SAVING_PAGE<<RTL8368S_PHY_PAGE_OFFSET)&RTL8368S_PHY_PAGE_MASK)
|
(RTL8368S_POWER_SAVING_REG&RTL8368S_PHY_REG_MASK);
retVal = rtl8368s_setAsicReg(phySmiAddr, 0);
if (retVal != SUCCESS)
return retVal;
The PHYs are accessed here in memory area 0x8000.
Fixed the rest, thanks!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] net: sched: split tc_ctl_tfilter into three handlers
From: David Miller @ 2018-05-29 20:04 UTC (permalink / raw)
To: vladbu; +Cc: netdev, jhs, xiyou.wangcong, jiri, kliteyn
In-Reply-To: <1527450903-11408-1-git-send-email-vladbu@mellanox.com>
From: Vlad Buslov <vladbu@mellanox.com>
Date: Sun, 27 May 2018 22:55:03 +0300
> tc_ctl_tfilter handles three netlink message types: RTM_NEWTFILTER,
> RTM_DELTFILTER, RTM_GETTFILTER. However, implementation of this function
> involves a lot of branching on specific message type because most of the
> code is message-specific. This significantly complicates adding new
> functionality and doesn't provide much benefit of code reuse.
>
> Split tc_ctl_tfilter to three standalone functions that handle filter new,
> delete and get requests.
>
> The only truly protocol independent part of tc_ctl_tfilter is code that
> looks up queue, class, and block. Refactor this code to standalone
> tcf_block_find function that is used by all three new handlers.
>
> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
This looks fine but doesn't apply cleanly to net-next.
^ permalink raw reply
* Re: [PATCH rdma-next 0/3] Introduce new mlx5 CQE format
From: Jason Gunthorpe @ 2018-05-29 20:05 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Guy Levi,
Yishai Hadas, Yonatan Cohen, Saeed Mahameed, linux-netdev
In-Reply-To: <20180527104234.17261-1-leon@kernel.org>
On Sun, May 27, 2018 at 01:42:31PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Introduce new internal to mlx5 CQE format - mini-CQE. It is a CQE in
> compressed form that holds data needed to extra a single full CQE.
>
> It stride index, byte count and packet checksum.
>
> Thanks
>
> Yonatan Cohen (3):
> net/mlx5: Exposing a new mini-CQE format
> IB/mlx5: Refactor CQE compression response
> IB/mlx5: Introduce a new mini-CQE format
Applied to for-next.
Generally taking new uapi patches that are first the list should have
a few weeks of comment period, but since this is just adding a new bit
to an existing driver private api it seems OK to go this merge window.
Thanks,
Jason
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Andrew Lunn @ 2018-05-29 20:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Heiner Kallweit, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <CACRpkdaKZC2YHYO_xLEtTB6DYW4FpapNBe4KQSCO57iHmCLZvw@mail.gmail.com>
On Tue, May 29, 2018 at 10:01:14PM +0200, Linus Walleij wrote:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> >> +#define RTL8366RB_POWER_SAVE 0x21
>
> > Typically PHY register addresses are 5 bits wide, is 0x21 correct
> > and I miss something?
Heiner is correct, MDIO only supports 32 register, when using clause
22. However, your device is not clause 22, it is its own thing. So one
danger you have is that we put some checks in the generic code testing
for values > 31, and return -EINVAL.
I think you have two choices:
1) A comment explaining what is going on here, how 0x21 is valid in
this context. And check the return value and give out a good warning
which will point somebody in the right direction to notice this 0x21.
2) Move this into the DSA driver, which does not have this
restriction.
Andrew
^ permalink raw reply
* Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Jason Gunthorpe @ 2018-05-29 20:21 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <14063C7AD467DE4B82DEDB5C278E8663B38ED738@FMSMSX108.amr.corp.intel.com>
On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
> >- struct ib_uverbs_destroy_cq_resp resp;
> > struct ib_uobject *uobj =
> >- uverbs_attr_get(attrs,
> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
> >- uobject);
> >+ uverbs_attr_get_uobject(attrs,
> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
> >+ struct ib_uverbs_destroy_cq_resp resp;
> >+ struct ib_ucq_object *obj;
> > int ret;
> >
> >+ if (IS_ERR(uobj))
> >+ return PTR_ERR(uobj);
> >+
>
> I remember a conversation that if an method attribute was mandatory, that you did not need to
> test the uobj for error (since it was checked in the infrastructure).
Yes.
> Is this error check necessary?
No
But there is no way to check one way or the other at compile time
right now, and omitting the check makes smatch mad.
We need some more patches to be able to safely omit the check...
Jason
^ permalink raw reply
* [PATCH bpf-next] bpftool: Support sendmsg{4,6} attach types
From: Andrey Ignatov @ 2018-05-29 20:29 UTC (permalink / raw)
To: netdev; +Cc: Andrey Ignatov, ast, daniel, kubakici, quentin.monnet,
kernel-team
Add support for recently added BPF_CGROUP_UDP4_SENDMSG and
BPF_CGROUP_UDP6_SENDMSG attach types to bpftool, update documentation
and bash completion.
Signed-off-by: Andrey Ignatov <rdna@fb.com>
---
I'm not sure about "since 4.18" in Documentation part. I can follow-up when
the next kernel version is known.
---
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 9 +++++++--
tools/bpf/bpftool/bash-completion/bpftool | 5 +++--
tools/bpf/bpftool/cgroup.c | 4 +++-
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
index d004f63..7b0e6d4 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-cgroup.rst
@@ -27,7 +27,8 @@ MAP COMMANDS
|
| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
| *ATTACH_TYPE* := { **ingress** | **egress** | **sock_create** | **sock_ops** | **device** |
-| **bind4** | **bind6** | **post_bind4** | **post_bind6** | **connect4** | **connect6** }
+| **bind4** | **bind6** | **post_bind4** | **post_bind6** | **connect4** | **connect6** |
+| **sendmsg4** | **sendmsg6** }
| *ATTACH_FLAGS* := { **multi** | **override** }
DESCRIPTION
@@ -70,7 +71,11 @@ DESCRIPTION
**post_bind4** return from bind(2) for an inet4 socket (since 4.17);
**post_bind6** return from bind(2) for an inet6 socket (since 4.17);
**connect4** call to connect(2) for an inet4 socket (since 4.17);
- **connect6** call to connect(2) for an inet6 socket (since 4.17).
+ **connect6** call to connect(2) for an inet6 socket (since 4.17);
+ **sendmsg4** call to sendto(2), sendmsg(2), sendmmsg(2) for an
+ unconnected udp4 socket (since 4.18);
+ **sendmsg6** call to sendto(2), sendmsg(2), sendmmsg(2) for an
+ unconnected udp6 socket (since 4.18).
**bpftool cgroup detach** *CGROUP* *ATTACH_TYPE* *PROG*
Detach *PROG* from the cgroup *CGROUP* and attach type
diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
index 7bc198d..1e10833 100644
--- a/tools/bpf/bpftool/bash-completion/bpftool
+++ b/tools/bpf/bpftool/bash-completion/bpftool
@@ -407,7 +407,7 @@ _bpftool()
attach|detach)
local ATTACH_TYPES='ingress egress sock_create sock_ops \
device bind4 bind6 post_bind4 post_bind6 connect4 \
- connect6'
+ connect6 sendmsg4 sendmsg6'
local ATTACH_FLAGS='multi override'
local PROG_TYPE='id pinned tag'
case $prev in
@@ -416,7 +416,8 @@ _bpftool()
return 0
;;
ingress|egress|sock_create|sock_ops|device|bind4|bind6|\
- post_bind4|post_bind6|connect4|connect6)
+ post_bind4|post_bind6|connect4|connect6|sendmsg4|\
+ sendmsg6)
COMPREPLY=( $( compgen -W "$PROG_TYPE" -- \
"$cur" ) )
return 0
diff --git a/tools/bpf/bpftool/cgroup.c b/tools/bpf/bpftool/cgroup.c
index 1351bd6..16bee01 100644
--- a/tools/bpf/bpftool/cgroup.c
+++ b/tools/bpf/bpftool/cgroup.c
@@ -20,7 +20,7 @@
" ATTACH_TYPE := { ingress | egress | sock_create |\n" \
" sock_ops | device | bind4 | bind6 |\n" \
" post_bind4 | post_bind6 | connect4 |\n" \
- " connect6 }"
+ " connect6 | sendmsg4 | sendmsg6 }"
static const char * const attach_type_strings[] = {
[BPF_CGROUP_INET_INGRESS] = "ingress",
@@ -34,6 +34,8 @@ static const char * const attach_type_strings[] = {
[BPF_CGROUP_INET6_CONNECT] = "connect6",
[BPF_CGROUP_INET4_POST_BIND] = "post_bind4",
[BPF_CGROUP_INET6_POST_BIND] = "post_bind6",
+ [BPF_CGROUP_UDP4_SENDMSG] = "sendmsg4",
+ [BPF_CGROUP_UDP6_SENDMSG] = "sendmsg6",
[__MAX_BPF_ATTACH_TYPE] = NULL,
};
--
2.9.5
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net: Add support to configure SR-IOV VF minimum and maximum queues.
From: Samudrala, Sridhar @ 2018-05-29 20:46 UTC (permalink / raw)
To: Michael Chan, davem; +Cc: netdev
In-Reply-To: <1527581920-3778-2-git-send-email-michael.chan@broadcom.com>
On 5/29/2018 1:18 AM, Michael Chan wrote:
> VF Queue resources are always limited and there is currently no
> infrastructure to allow the admin. on the host to add or reduce queue
> resources for any particular VF. With ever increasing number of VFs
> being supported, it is desirable to allow the admin. to configure queue
> resources differently for the VFs. Some VFs may require more or fewer
> queues due to different bandwidth requirements or different number of
> vCPUs in the VM. This patch adds the infrastructure to do that by
> adding IFLA_VF_QUEUES netlink attribute and a new .ndo_set_vf_queues()
> to the net_device_ops.
>
> Four parameters are exposed for each VF:
>
> o min_tx_queues - Guaranteed tx queues available to the VF.
>
> o max_tx_queues - Maximum but not necessarily guaranteed tx queues
> available to the VF.
>
> o min_rx_queues - Guaranteed rx queues available to the VF.
>
> o max_rx_queues - Maximum but not necessarily guaranteed rx queues
> available to the VF.
>
> The "ip link set" command will subsequently be patched to support the new
> operation to set the above parameters.
>
> After the admin. makes a change to the above parameters, the corresponding
> VF will have a new range of channels to set using ethtool -L. The VF may
> have to go through IF down/up before the new queues will take effect. Up
> to the min values are guaranteed. Up to the max values are possible but not
> guaranteed.
>
> Signed-off-by: Michael Chan <michael.chan@broadcom.com>
> ---
> include/linux/if_link.h | 4 ++++
> include/linux/netdevice.h | 6 ++++++
> include/uapi/linux/if_link.h | 9 +++++++++
> net/core/rtnetlink.c | 32 +++++++++++++++++++++++++++++---
> 4 files changed, 48 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/if_link.h b/include/linux/if_link.h
> index 622658d..8e81121 100644
> --- a/include/linux/if_link.h
> +++ b/include/linux/if_link.h
> @@ -29,5 +29,9 @@ struct ifla_vf_info {
> __u32 rss_query_en;
> __u32 trusted;
> __be16 vlan_proto;
> + __u32 min_tx_queues;
> + __u32 max_tx_queues;
> + __u32 min_rx_queues;
> + __u32 max_rx_queues;
> };
> #endif /* _LINUX_IF_LINK_H */
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 8452f72..17f5892 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1023,6 +1023,8 @@ struct dev_ifalias {
> * with PF and querying it may introduce a theoretical security risk.
> * int (*ndo_set_vf_rss_query_en)(struct net_device *dev, int vf, bool setting);
> * int (*ndo_get_vf_port)(struct net_device *dev, int vf, struct sk_buff *skb);
> + * int (*ndo_set_vf_queues)(struct net_device *dev, int vf, int min_txq,
> + * int max_txq, int min_rxq, int max_rxq);
Isn't ndo_set_vf_xxx() considered a legacy interface and not planned to be extended?
Shouldn't we enable this via ethtool on the port representor netdev?
^ permalink raw reply
* RE: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Ruhl, Michael J @ 2018-05-29 20:49 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <20180529202119.GK18442@mellanox.com>
>-----Original Message-----
>From: Jason Gunthorpe [mailto:jgg@mellanox.com]
>Sent: Tuesday, May 29, 2018 4:21 PM
>To: Ruhl, Michael J <michael.j.ruhl@intel.com>
>Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
><dledford@redhat.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
>mailing list <linux-rdma@vger.kernel.org>; Boris Pismenny
><borisp@mellanox.com>; Matan Barak <matanb@mellanox.com>; Raed
>Salem <raeds@mellanox.com>; Yishai Hadas <yishaih@mellanox.com>; Saeed
>Mahameed <saeedm@mellanox.com>; linux-netdev
><netdev@vger.kernel.org>
>Subject: Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter
>to ioctl() infrastructure
>
>On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
>> >- struct ib_uverbs_destroy_cq_resp resp;
>> > struct ib_uobject *uobj =
>> >- uverbs_attr_get(attrs,
>> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
>> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
>> >- uobject);
>> >+ uverbs_attr_get_uobject(attrs,
>> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
>> >+ struct ib_uverbs_destroy_cq_resp resp;
>> >+ struct ib_ucq_object *obj;
>> > int ret;
>> >
>> >+ if (IS_ERR(uobj))
>> >+ return PTR_ERR(uobj);
>> >+
>>
>> I remember a conversation that if an method attribute was mandatory, that
>you did not need to
>> test the uobj for error (since it was checked in the infrastructure).
>
>Yes.
>
>> Is this error check necessary?
>
>No
>
>But there is no way to check one way or the other at compile time
>right now, and omitting the check makes smatch mad.
Is smatch going to get mad at (same patch):
diff --git a/drivers/infiniband/core/uverbs_std_types_flow_action.c b/drivers/infiniband/core/uverbs_std_types_flow_action.c
index b4f016dfa23d..a7be51cf2e42 100644
--- a/drivers/infiniband/core/uverbs_std_types_flow_action.c
+++ b/drivers/infiniband/core/uverbs_std_types_flow_action.c
@@ -320,7 +320,7 @@ static int UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_CREATE)(struct ib_device
return ret;
/* No need to check as this attribute is marked as MANDATORY */
- uobj = uverbs_attr_get(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
+ uobj = uverbs_attr_get_uobject(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
action = ib_dev->create_flow_action_esp(ib_dev, &esp_attr.hdr, attrs);
if (IS_ERR(action))
return PTR_ERR(action);
@@ -350,7 +350,7 @@ static int UVERBS_HANDLER(UVERBS_METHOD_FLOW_ACTION_ESP_MODIFY)(struct ib_device
if (ret)
return ret;
- uobj = uverbs_attr_get(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE)->obj_attr.uobject;
+ uobj = uverbs_attr_get_uobject(attrs, UVERBS_ATTR_FLOW_ACTION_ESP_HANDLE);
action = uobj->object;
?
If not,
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Thanks,
Mike
>We need some more patches to be able to safely omit the check...
>
>Jason
^ permalink raw reply related
* Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter to ioctl() infrastructure
From: Jason Gunthorpe @ 2018-05-29 20:51 UTC (permalink / raw)
To: Ruhl, Michael J
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Boris Pismenny, Matan Barak, Raed Salem, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <14063C7AD467DE4B82DEDB5C278E8663B38EE87B@FMSMSX108.amr.corp.intel.com>
On Tue, May 29, 2018 at 08:49:58PM +0000, Ruhl, Michael J wrote:
> >From: Jason Gunthorpe [mailto:jgg@mellanox.com]
> >Sent: Tuesday, May 29, 2018 4:21 PM
> >To: Ruhl, Michael J <michael.j.ruhl@intel.com>
> >Cc: Leon Romanovsky <leon@kernel.org>; Doug Ledford
> ><dledford@redhat.com>; Leon Romanovsky <leonro@mellanox.com>; RDMA
> >mailing list <linux-rdma@vger.kernel.org>; Boris Pismenny
> ><borisp@mellanox.com>; Matan Barak <matanb@mellanox.com>; Raed
> >Salem <raeds@mellanox.com>; Yishai Hadas <yishaih@mellanox.com>; Saeed
> >Mahameed <saeedm@mellanox.com>; linux-netdev
> ><netdev@vger.kernel.org>
> >Subject: Re: [PATCH rdma-next v2 01/13] IB/uverbs: Add an ib_uobject getter
> >to ioctl() infrastructure
> >
> >On Tue, May 29, 2018 at 07:31:22PM +0000, Ruhl, Michael J wrote:
> >> >- struct ib_uverbs_destroy_cq_resp resp;
> >> > struct ib_uobject *uobj =
> >> >- uverbs_attr_get(attrs,
> >> >UVERBS_ATTR_DESTROY_CQ_HANDLE)->obj_attr.uobject;
> >> >- struct ib_ucq_object *obj = container_of(uobj, struct ib_ucq_object,
> >> >- uobject);
> >> >+ uverbs_attr_get_uobject(attrs,
> >> >UVERBS_ATTR_DESTROY_CQ_HANDLE);
> >> >+ struct ib_uverbs_destroy_cq_resp resp;
> >> >+ struct ib_ucq_object *obj;
> >> > int ret;
> >> >
> >> >+ if (IS_ERR(uobj))
> >> >+ return PTR_ERR(uobj);
> >> >+
> >>
> >> I remember a conversation that if an method attribute was mandatory, that
> >you did not need to
> >> test the uobj for error (since it was checked in the infrastructure).
> >
> >Yes.
> >
> >> Is this error check necessary?
> >
> >No
> >
> >But there is no way to check one way or the other at compile time
> >right now, and omitting the check makes smatch mad.
>
> Is smatch going to get mad at (same patch):
Yes, this is where it already got mad, IIRC :(
Fixing this whole thing is a todo on my list..
Jason
^ permalink raw reply
* Re: [PATCH mlx5-next 1/3] net/mlx5: Exposing a new mini-CQE format
From: Saeed Mahameed @ 2018-05-29 21:01 UTC (permalink / raw)
To: Jason Gunthorpe, leon@kernel.org, dledford@redhat.com
Cc: Yonatan Cohen, netdev@vger.kernel.org, Guy Levi(SW),
Leon Romanovsky, linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <20180527104234.17261-2-leon@kernel.org>
On Sun, 2018-05-27 at 13:42 +0300, Leon Romanovsky wrote:
> From: Yonatan Cohen <yonatanc@mellanox.com>
>
> The new mini-CQE format includes byte-count, checksum
> and stride index.
>
> Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> Reviewed-by: Guy Levi <guyle@mellanox.com>
> Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Applied to mlx5-next.
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-
next
commit-id: ab741b2eed3e456cebd2240d4c9c6be003d5ae72
Thanks!
^ permalink raw reply
* Re: [1/4,RFCv2] net: phy: realtek: Support RTL8366RB variant
From: Heiner Kallweit @ 2018-05-29 21:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Andrew Lunn, Vivien Didelot, Florian Fainelli, netdev,
OpenWrt Development List, LEDE Development List,
Antti Seppälä, Roman Yeryomin, Colin Leitner,
Gabor Juhos
In-Reply-To: <CACRpkdaKZC2YHYO_xLEtTB6DYW4FpapNBe4KQSCO57iHmCLZvw@mail.gmail.com>
Am 29.05.2018 um 22:01 schrieb Linus Walleij:
> On Tue, May 29, 2018 at 8:51 PM, Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
>>> +#define RTL8366RB_POWER_SAVE 0x21
>
>> Typically PHY register addresses are 5 bits wide, is 0x21 correct
>> and I miss something?
>
> If it is correct I don't know, but it appears in the vendor
> code:
>
> /*Power Saving*/
> #define RTL8368S_POWER_SAVING_PAGE 0
> #define RTL8368S_POWER_SAVING_REG 21
This is a decimal number .. You use 0x21.
> #define RTL8368S_POWER_SAVING_BIT_MSK 0x1000
>
> Then:
>
> phySmiAddr = 0x8000 | (1<<(phyNo +RTL8368S_PHY_NO_OFFSET)) |
>
> ((RTL8368S_POWER_SAVING_PAGE<<RTL8368S_PHY_PAGE_OFFSET)&RTL8368S_PHY_PAGE_MASK)
> |
> (RTL8368S_POWER_SAVING_REG&RTL8368S_PHY_REG_MASK);
>
> retVal = rtl8368s_setAsicReg(phySmiAddr, 0);
> if (retVal != SUCCESS)
> return retVal;
>
> The PHYs are accessed here in memory area 0x8000.
>
> Fixed the rest, thanks!
>
> Yours,
> Linus Walleij
>
^ permalink raw reply
* Re: [PATCH net-next 0/7] net/ipv6: Fix route append and replace use cases
From: Thomas Winter @ 2018-05-29 21:16 UTC (permalink / raw)
To: David Ahern, David Miller, dsahern@kernel.org
Cc: netdev@vger.kernel.org, idosch@mellanox.com,
sharpd@cumulusnetworks.com, roopa@cumulusnetworks.com
In-Reply-To: <6d61c529-5b51-dc3b-86ee-e912f1a8e0a8@gmail.com>
The only thing this breaks is adding IPv6 routes via ioctl. Previously they would be automatically appended to form multipath routes but this no longer occurs. Changing to netlink or use iproute2 and using NLM_F_APPEND gets around this. This basically what David Ahern said earlier but I wanted to make it clear the default ioctl behaviour has changed.
________________________________________
From: David Ahern <dsahern@gmail.com>
Sent: 23 May 2018 08:44
To: David Miller; dsahern@kernel.org
Cc: netdev@vger.kernel.org; Thomas Winter; idosch@mellanox.com; sharpd@cumulusnetworks.com; roopa@cumulusnetworks.com
Subject: Re: [PATCH net-next 0/7] net/ipv6: Fix route append and replace use cases
On 5/22/18 12:46 PM, David Miller wrote:
>
> Ok, I'll apply this series.
>
> But if this breaks things for anyone in a practical way, I am unfortunately
> going to have to revert no matter how silly the current behavior may be.
>
Understood. I have to try the best option first. I'll look at
regressions if they happen.
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: Support sendmsg{4,6} attach types
From: Jakub Kicinski @ 2018-05-29 21:20 UTC (permalink / raw)
To: Andrey Ignatov; +Cc: netdev, ast, daniel, quentin.monnet, kernel-team
In-Reply-To: <20180529202931.538817-1-rdna@fb.com>
On Tue, 29 May 2018 13:29:31 -0700, Andrey Ignatov wrote:
> Add support for recently added BPF_CGROUP_UDP4_SENDMSG and
> BPF_CGROUP_UDP6_SENDMSG attach types to bpftool, update documentation
> and bash completion.
>
> Signed-off-by: Andrey Ignatov <rdna@fb.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> I'm not sure about "since 4.18" in Documentation part. I can follow-up when
> the next kernel version is known.
IMHO it's fine, we can follow up if Linus decides to call it something
else :)
Thanks!
^ permalink raw reply
* Re: [PATCH mlx5-next 1/3] net/mlx5: Exposing a new mini-CQE format
From: Jason Gunthorpe @ 2018-05-29 21:35 UTC (permalink / raw)
To: Saeed Mahameed
Cc: leon@kernel.org, dledford@redhat.com, Yonatan Cohen,
netdev@vger.kernel.org, Guy Levi(SW), Leon Romanovsky,
linux-rdma@vger.kernel.org, Yishai Hadas
In-Reply-To: <7aba104bb1313c1cda01baae2ff8495d5623f4b1.camel@mellanox.com>
On Tue, May 29, 2018 at 03:01:27PM -0600, Saeed Mahameed wrote:
> On Sun, 2018-05-27 at 13:42 +0300, Leon Romanovsky wrote:
> > From: Yonatan Cohen <yonatanc@mellanox.com>
> >
> > The new mini-CQE format includes byte-count, checksum
> > and stride index.
> >
> > Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
> > Reviewed-by: Guy Levi <guyle@mellanox.com>
> > Signed-off-by: Yonatan Cohen <yonatanc@mellanox.com>
> > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
>
>
> Applied to mlx5-next.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git mlx5-
> next
>
> commit-id: ab741b2eed3e456cebd2240d4c9c6be003d5ae72
Thanks, everything is now merged as:
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=wip/jgg-for-next&id=f3ca0ab114e0de3bbad4c4a537d32fb57aa42f81
Jason
^ permalink raw reply
* Re: [PATCH net-next 0/8] nfp: offload LAG for tc flower egress
From: Jiri Pirko @ 2018-05-29 22:09 UTC (permalink / raw)
To: John Hurley
Cc: Jakub Kicinski, David Miller, Linux Netdev List, oss-drivers,
Jay Vosburgh, Veaceslav Falico, Andy Gospodarek
In-Reply-To: <CAK+XE=kAM=sv4vpSKuyaiHzdLCNZUwuEL0ggODCQnsM+sfCw8w@mail.gmail.com>
Tue, May 29, 2018 at 04:08:48PM CEST, john.hurley@netronome.com wrote:
>On Sat, May 26, 2018 at 3:47 AM, Jakub Kicinski
><jakub.kicinski@netronome.com> wrote:
>> On Fri, 25 May 2018 08:48:09 +0200, Jiri Pirko wrote:
>>> Thu, May 24, 2018 at 04:22:47AM CEST, jakub.kicinski@netronome.com wrote:
>>> >Hi!
>>> >
>>> >This series from John adds bond offload to the nfp driver. Patch 5
>>> >exposes the hash type for NETDEV_LAG_TX_TYPE_HASH to make sure nfp
>>> >hashing matches that of the software LAG. This may be unnecessarily
>>> >conservative, let's see what LAG maintainers think :)
>>>
>>> So you need to restrict offload to only certain hash algo? In mlxsw, we
>>> just ignore the lag setting and do some hw default hashing. Would not be
>>> enough? Note that there's a good reason for it, as you see, in team, the
>>> hashing is done in a BPF function and could be totally arbitrary.
>>> Your patchset effectively disables team offload for nfp.
>>
>> My understanding is that the project requirements only called for L3/L4
>> hash algorithm offload, hence the temptation to err on the side of
>> caution and not offload all the bond configurations. John can provide
>> more details. Not being able to offload team is unfortunate indeed.
>
>Hi Jiri,
>Yes, as Jakub mentions, we restrict ourselves to L3/L4 hash algorithm
>as this is currently what is supported in fw.
In mlxsw, a default l3/l4 is used always, no matter what the
bonding/team sets. It is not correct, but it works with team as well.
Perhaps we can have NETDEV_LAG_HASH_UNKNOWN to indicate to the driver to
do some default? That would make the "team" offload functional.
>Hopefully this will change as fw features are expanded.
>I understand the issue this presents with offloading team.
>Perhaps resorting to a default hw hash for team is acceptable.
>John
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox