* Re: [PATCH net-next] net: ethtool: silence kmalloc warning
From: David Miller @ 2017-01-30 20:50 UTC (permalink / raw)
To: ast; +Cc: edumazet, netdev
In-Reply-To: <1485652625-2881838-1-git-send-email-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Sat, 28 Jan 2017 17:17:05 -0800
> under memory pressure 'ethtool -S' command may warn:
> [ 2374.385195] ethtool: page allocation failure: order:4, mode:0x242c0c0
...
> ~1160 mlx5 counters ~= order 4 allocation which is unlikely to succeed
> under memory pressure. Since 'get stats' command is not critical
> avoid reclaim and warning.
> Also convert to safer kmalloc_array.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Let's just fix this right, just like in ethtool_get_regs().
Just use vzalloc() unconditionally. It is an entirely similar
situation. But please be careful with the size calculations when
you make this adjustment.
Thank you.
^ permalink raw reply
* [PATCH net-next v5 2/4] net: dsa: b53: Add mirror capture register definitions
From: Florian Fainelli @ 2017-01-30 20:41 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, jiri, Florian Fainelli
In-Reply-To: <20170130204143.539-1-f.fainelli@gmail.com>
Add definitions for the different Roboswitch registers relevant for
ingress and egress mirroring.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_regs.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index dac0af4e2cd0..9fd24c418fa4 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -206,6 +206,38 @@
#define BRCM_HDR_P8_EN BIT(0) /* Enable tagging on port 8 */
#define BRCM_HDR_P5_EN BIT(1) /* Enable tagging on port 5 */
+/* Mirror capture control register (16 bit) */
+#define B53_MIR_CAP_CTL 0x10
+#define CAP_PORT_MASK 0xf
+#define BLK_NOT_MIR BIT(14)
+#define MIRROR_EN BIT(15)
+
+/* Ingress mirror control register (16 bit) */
+#define B53_IG_MIR_CTL 0x12
+#define MIRROR_MASK 0x1ff
+#define DIV_EN BIT(13)
+#define MIRROR_FILTER_MASK 0x3
+#define MIRROR_FILTER_SHIFT 14
+#define MIRROR_ALL 0
+#define MIRROR_DA 1
+#define MIRROR_SA 2
+
+/* Ingress mirror divider register (16 bit) */
+#define B53_IG_MIR_DIV 0x14
+#define IN_MIRROR_DIV_MASK 0x3ff
+
+/* Ingress mirror MAC address register (48 bit) */
+#define B53_IG_MIR_MAC 0x16
+
+/* Egress mirror control register (16 bit) */
+#define B53_EG_MIR_CTL 0x1C
+
+/* Egress mirror divider register (16 bit) */
+#define B53_EG_MIR_DIV 0x1E
+
+/* Egress mirror MAC address register (48 bit) */
+#define B53_EG_MIR_MAC 0x20
+
/* Device ID register (8 or 32 bit) */
#define B53_DEVICE_ID 0x30
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net] ipv6: Paritially checksum full MTU frames
From: David Miller @ 2017-01-30 20:51 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, vyasevic
In-Reply-To: <1485748373-14909-1-git-send-email-vyasevic@redhat.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Sun, 29 Jan 2017 22:52:53 -0500
> IPv6 will mark data that is smaller that mtu - headersize as
> CHECKSUM_PARTIAL, but if the data will completely fill the mtu,
> the packet checksum will be computed in software instead.
> Extend the conditional to include the data that fills the mtu
> as well.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
Looks good, applied, thanks!
^ permalink raw reply
* Re: [PATCH net-next v5 0/4] net: dsa: Port mirroring support
From: David Miller @ 2017-01-30 20:57 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, jiri
In-Reply-To: <20170130204143.539-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 30 Jan 2017 12:41:39 -0800
...
> David, this will most likely conflict a little bit with my other series:
> net: dsa: bcm_sf2: CFP support, so just let me know if that happens, and
> I will provide a rebased version. Thanks!
Since you have resolved this, I am going to remove this text from the
merge commit message.
> Changes in v5:
>
> - Added Jiri's Reviewed-by tag to first patch
> - rebase against latest net-next/master after bcm_sf2 CFP series
...
Thanks for respinning.
Applied, thanks!
^ permalink raw reply
* [PATCH net-next v5 0/4] net: dsa: Port mirroring support
From: Florian Fainelli @ 2017-01-30 20:41 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, jiri, Florian Fainelli
Hi all,
This patch series adds support for port mirroring in the two
Broadcom switch drivers. The major part of the functional are actually with
the plumbing between tc and the drivers.
David, this will most likely conflict a little bit with my other series:
net: dsa: bcm_sf2: CFP support, so just let me know if that happens, and
I will provide a rebased version. Thanks!
Changes in v5:
- Added Jiri's Reviewed-by tag to first patch
- rebase against latest net-next/master after bcm_sf2 CFP series
Changes in v4:
- rebased against latest net-next/master after Vivien's changes
Changes in v3:
- removed multiline comments from added structures
- simplify error handling in dsa_slave_add_cls_matchall
Changes in v2:
- fixed filter removal logic to disable the ingress or egress mirroring
when there are no longer ports being monitored in ingress or egress
- removed a stray list_head in dsa_port structure that is not used
Tested using the two iproute2 examples:
# ingress
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: \
matchall skip_sw \
action mirred egress mirror \
dev eth2
# egress
tc qdisc add dev eth1 handle 1: root prio
tc filter add dev eth1 parent 1: \
matchall skip_sw \
action mirred egress mirror \
dev eth2
Florian Fainelli (4):
net: dsa: Add plumbing for port mirroring
net: dsa: b53: Add mirror capture register definitions
net: dsa: b53: Add support for port mirroring
net: dsa: bcm_sf2: Add support for port mirroring
drivers/net/dsa/b53/b53_common.c | 67 +++++++++++++++++++
drivers/net/dsa/b53/b53_priv.h | 4 ++
drivers/net/dsa/b53/b53_regs.h | 32 +++++++++
drivers/net/dsa/bcm_sf2.c | 2 +
include/net/dsa.h | 33 ++++++++++
net/dsa/dsa_priv.h | 3 +
net/dsa/slave.c | 137 ++++++++++++++++++++++++++++++++++++++-
7 files changed, 277 insertions(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* Re: [PATCH net-next v2] lwtunnel: remove device arg to lwtunnel_build_state
From: Roopa Prabhu @ 2017-01-30 21:12 UTC (permalink / raw)
To: David Ahern; +Cc: netdev
In-Reply-To: <1485806857-3651-1-git-send-email-dsa@cumulusnetworks.com>
On 1/30/17, 12:07 PM, David Ahern wrote:
> Nothing about lwt state requires a device reference, so remove the
> input argument.
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
> ---
> v2
> - rebased to top of net-next tree
>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
thanks David
^ permalink raw reply
* Re: [PATCHv3 perf/core 1/6] tools lib bpf: Add BPF program pinning APIs.
From: Joe Stringer @ 2017-01-30 21:16 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Wang Nan, ast, Daniel Borkmann, LKML, netdev
In-Reply-To: <20170130202813.GG4546@kernel.org>
On 30 January 2017 at 12:28, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> Em Mon, Jan 30, 2017 at 05:25:06PM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Thu, Jan 26, 2017 at 01:19:56PM -0800, Joe Stringer escreveu:
>> > Add new APIs to pin a BPF program (or specific instances) to the filesystem.
>> > The user can specify the path full path within a BPF filesystem to pin the
>> > program.
>> >
>> > bpf_program__pin_instance(prog, path, n) will pin the nth instance of
>> > 'prog' to the specified path.
>> > bpf_program__pin(prog, path) will create the directory 'path' (if it
>> > does not exist) and pin each instance within that directory. For
>> > instance, path/0, path/1, path/2.
>> >
>> > Signed-off-by: Joe Stringer <joe@ovn.org>
>>
>> make: Entering directory '/home/acme/git/linux/tools/perf'
>> BUILD: Doing 'make -j4' parallel build
>> CC /tmp/build/perf/builtin-record.o
>> CC /tmp/build/perf/libbpf.o
>> CC /tmp/build/perf/util/parse-events.o
>> INSTALL trace_plugins
>> libbpf.c: In function ‘make_dir’:
>> libbpf.c:1303:6: error: implicit declaration of function ‘mkdir’ [-Werror=implicit-function-declaration]
>> if (mkdir(path, 0700) && errno != EEXIST)
>> ^~~~~
>> libbpf.c:1303:2: error: nested extern declaration of ‘mkdir’ [-Werror=nested-externs]
>> if (mkdir(path, 0700) && errno != EEXIST)
>> ^~
>> cc1: all warnings being treated as errors
>> mv: cannot stat '/tmp/build/perf/.libbpf.o.tmp': No such file or directory
>> /home/acme/git/linux/tools/build/Makefile.build:101: recipe for target '/tmp/build/perf/libbpf.o' failed
Not sure why but I didn't see this. Appreciate the fix.
>>
>>
>> And strdup() is not checked for failure, I'm fixing those,
>>
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -36,6 +36,8 @@
>> #include <linux/magic.h>
>> #include <linux/list.h>
>> #include <linux/limits.h>
>> +#include <sys/stat.h>
>> +#include <sys/types.h>
>> #include <sys/vfs.h>
>
> This as well:
>
> @@ -1338,7 +1343,7 @@ int bpf_program__pin(struct bpf_program *prog,
> const char *path)
> len = snprintf(buf, PATH_MAX, "%s/%d", path, i);
> if (len < 0)
> return -EINVAL;
> - else if (len > PATH_MAX)
> + else if (len >= PATH_MAX)
> return -ENAMETOOLONG;
>
>
> See 'man snprintf', return value:
>
> ---
> Thus, a return value of size or more means that the output was
> truncated.
> ---
Good spotting, I looked over the committed versions and tested them,
they seem good to me. Thanks!
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: Stephen Hemminger @ 2017-01-30 21:16 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: David Ahern, netdev, nicolas.dichtel
In-Reply-To: <588F89E5.9060503@cumulusnetworks.com>
On Mon, 30 Jan 2017 10:45:57 -0800
Roopa Prabhu <roopa@cumulusnetworks.com> wrote:
> On 1/30/17, 8:12 AM, David Ahern wrote:
> > On 1/30/17 8:49 AM, Roopa Prabhu wrote:
> >>> Single next hop delete will be around because IPv6 allows it -- and because IPv4 needs to support it.
> >>>
> >> understand single next hop delete for ipv6 will be around..and my only point was to leave it around but not optimize for that case.
> >> I don't think we should support single nexthop delete in ipv4 (I have not seen a requirement for that)... ipv4 is good as it is right now.
> >> the additional complexity is not needed.
> >>
> > IPv4 has a known bug -- delete a virtual interface in a multihop route and the entire route is deleted, including the nexthops for other devices. This does not happen for IPv6.
> >
> > Simple example of that bug:
> >
> > ip li add dummy1 type dummy
> > ip li add dummy2 type dummy
> > ip addr add dev dummy1 10.11.1.1/28
> > ip li set dummy1 up
> > ip addr add dev dummy2 10.11.2.1/28
> > ip li set dummy2 up
> > ip ro add 1.1.1.0/24 nexthop via 10.11.1.2 nexthop via 10.11.2.2
> > ip li del dummy2
> >
> > --> the entire multipath route has been deleted.
> >
> >
> > And, fixing this bug enables work to make IPv4 append to be sane -- appending a route should modify an existing route by adding the nexthop, not adding a new route that I believe can never actually be hit.
> >
> > Both cases mean modifying an IPv4 route -- adding or removing nexthops -- a capability that IPv6 allows so fixing this means closing another difference between the stacks.
>
> good point on the bug you point out. agree the bug needs to be fixed ...but routing daemons react to this behavior pretty well...because they get a link notification and a route notification. I was ok with fixing ipv6 to be similar to ipv4...but I am not in favor of bringing in design choices that ipv6 made into ipv4 :).
> In all cases, in my experience with routes, the update of ecmp route as a whole has always been ok (at-least not until now...maybe in the future
> for new usecases)
>
> In the case of the bug you point out, can the user be notified of the implicit update of the route in the kernel ...via replace flag or something ?.
> regarding append..., ipv4 never really supported appending to an existing route......even in the case of a non-ecmp routes.
> append just dictates the order where the route is added IIRC (i maybe mistaken here..its been long i tried it).
My fear is that routing daemons already adapt to the funny semantics of multi-path routing in IPv4 vs IPv6
and therefore any change in semantics or flags risks breaking existing user space.
^ permalink raw reply
* Re: [PATCH net-next 1/4] mlx5: Make building eswitch configurable
From: Saeed Mahameed @ 2017-01-30 21:18 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Tom Herbert, Or Gerlitz, Saeed Mahameed, David Miller,
Linux Netdev List, Kernel Team
In-Reply-To: <588F6DC7.70904@fb.com>
On Mon, Jan 30, 2017 at 6:45 PM, Alexei Starovoitov <ast@fb.com> wrote:
> On 1/29/17 1:11 AM, Saeed Mahameed wrote:
>>
>>
>> ConnectX4/5 and hopefully so on .. provide three different isolated
>> steering layers:
>>
>> 3. vport layer: avaialbe for any PF/VF vport nic driver instance
>> (netdevice), it allows vlan/mac filtering
>> ,RSS hashing and n-tuple steering (for both encapsulated and
>> nonencapsulated traffic) and RFS steering. ( the code above only
>> writes flow entries of a PF/VF to its own vport flow tables, there is
>> another mechanism to propagate l2 steering rules down to eswitch from
>> the vport layer.
>>
>> 2. eswitch layer: Available for PFs only with
>> HCA_CAP.vport_group_manager capability set.
>> it allows steering between PF and different VFs on the same host (vlan
>> mac steering and ACL filters in sriov legacy mode, and fancy n-tuple
>> steering and offloads for switchdev mode - eswitch_offloads.c - )
>> if this table is not create the default is pass-throu traffic to PF
>>
>> 1. L2 table: Available for PFs only with HCA_CAP.vport_group_manager
>> capability set.
>> needed for MH configurations and only PF is allowed and should write
>> "request UC MAC - set_l2_table_entry" on behalf of the PF itself and
>> it's own VFs.
>>
>> - On a bare metal machine only layer 3 is required (all traffic is
>> passed to the PF vport).
>> - On a MH configuration layer 3 and 1 are required.
>> - On a SRIOV configuration layer 3 and 2 are required.
>> - On MH with SRIOV all layers are required.
>>
>> in the driver, eswitch and L2 layers are handled by PF@eswitch.c.
>>
>> So for your question:
>>
>> PF always init_eswitch ( no eswitch -sriov- tables are created), and
>> the eswitch will start listening for vport_change_events.
>>
>> A PF/VF or netdev vport instance on any steering changes updates
>> should call mlx5e_vport_context_update[1]
>>
>> vport_context_update is A FW command that will store the current
>> UC/MC/VLAN list and promiscuity info of a vport.
>>
>> The FW will generate an event to the PF driver eswitch manager (vport
>> manager) mlx5_eswitch_vport_event [2], and the PF eswitch will call
>> set_l2_table_entry for each UC mac on each vport change event of any
>> vport (including its own vport), in case of SRIOV is enabled it will
>> update eswitch tables as well.
>>
>> To simplify my answer the function calls are:
>> Vport VF/PF netdevice:
>> mlx5e_set_rx_mode_work
>> mlx5e_vport_context_update
>> mlx5e_vport_context_update_addr_list --> FW event will be
>> generated to the PF esiwtch manager
>>
>> PF eswitch manager(eswitch.c) on a vport change FW event:
>> mlx5_eswitch_vport_event
>> esw_vport_change_handler
>> esw_vport_change_handle_locked
>> esw_apply_vport_addr_list
>> esw_add_uc_addr
>> set_l2_table_entry --> this will
>> update the l2 table in case MH is enabled.
>
>
> all makes sense. To test this logic I added printk-s
> to above functions, but I only see:
> # ip link set eth0 addr 24:8a:07:47:2b:6e
> [ 148.861914] mlx5e_vport_context_update_addr_list: is_uc 1 err 0
> [ 148.875152] mlx5e_vport_context_update_addr_list: is_uc 0 err 0
>
> MLX5_EVENT_TYPE_NIC_VPORT_CHANGE doesn't come into mlx5_eq_int().
Strange, just double checked and i got those events on latest net-next
bare-metal box.
> Yet nic seems to work fine. Packets come and go.
>
Is it multi host configuration or bare metal ?
Do you have internal loopback traffic between different hosts ?
> broken firmware or expected behavior?
which driver did you test ? backported or net-next ?
if it is backported driver please verify that on driver load the
following occurs :
1. VPORTS change events are globally enabled:
in mlx5_start_eqs@eq.c:
async_event_mask |= (1ull << MLX5_EVENT_TYPE_NIC_VPORT_CHANGE);
2. UC address change events are enabled for vport 0 (PF):
In eswitch_attach or on eswitch_init (depends on the kernel version) @eswitch.c
esw_enable_vport(esw, 0, UC_ADDR_CHANGE); is called.
>
> # ethtool -i eth0
> driver: mlx5_core
> version: 3.0-1 (January 2015)
> firmware-version: 14.16.2024
>
BTW folks, i am going to be on vacation for the rest of the week, so
please expect slow responses.
^ permalink raw reply
* Re: [PATCH net-next 0/4] mlx5: Create build configuration options
From: Saeed Mahameed @ 2017-01-30 21:26 UTC (permalink / raw)
To: Tom Herbert
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List, Kernel Team
In-Reply-To: <CALx6S36vBPMvsvDz2=9ipbsNGDaSXfSCR0Lwjdzt3AUTHOc8SA@mail.gmail.com>
On Mon, Jan 30, 2017 at 10:00 PM, Tom Herbert <tom@herbertland.com> wrote:
> On Sun, Jan 29, 2017 at 12:07 AM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>> On Sat, Jan 28, 2017 at 7:19 PM, Tom Herbert <tom@herbertland.com> wrote:
>>> On Sat, Jan 28, 2017 at 3:38 AM, Saeed Mahameed
>>> <saeedm@dev.mellanox.co.il> wrote:
>>>> On Fri, Jan 27, 2017 at 8:13 PM, Tom Herbert <tom@herbertland.com> wrote:
>>>>> On Fri, Jan 27, 2017 at 9:58 AM, Saeed Mahameed
>>>>> <saeedm@dev.mellanox.co.il> wrote:
>>>>>> On Fri, Jan 27, 2017 at 1:32 AM, Tom Herbert <tom@herbertland.com> wrote:
>>>>>>> This patchset creates configuration options for sriov, vxlan, eswitch,
>>>>>>> and tc features in the mlx5 driver. The purpose of this is to allow not
>>>>>>> building these features. These features are optional advanced features
>>>>>>> that are not required for a core Ethernet driver. A user can disable
>>>>>>> these features which resuces the amount of code in the driver. Disabling
>>>>>>> these features (and DCB) reduces the size of mlx5_core.o by about 16%.
>>>>>>> This is also can reduce the complexity of backport and rebases since
>>>>>>> user would no longer need to worry about dependencies with the rest of
>>>>>>> the kernel that features which might not be of any interest to a user
>>>>>>> may bring in.
>>>>>>>
>>>>>>> Tested: Build and ran the driver with all features enabled (the default)
>>>>>>> and with none enabled (including DCB). Did not see any issues. I did
>>>>>>> not explicity test operation of ayy of features in the list.
>>>>>>>
>>>>>>
>>>>>> Basically I am not against this kind of change, infact i am with it,
>>>>>> although I would have done some restructuring in the driver before i
>>>>>> did such change ;), filling the code with ifdefs is not a neat thing.
>>>>>>
>>>>> If you wish, please take this as an RFC and feel free to structure the
>>>>> code the right way. I think the intent is clear enough and looks like
>>>>> davem isn't going to allow the directory restructuring so something
>>>>> like this seems to be the best course of action now.
>>>>>
>>>>
>>>> Right.
>>>>
>>>>>> I agree this will simplify backporting and provide some kind of
>>>>>> feature separation inside the driver.
>>>>>> But this will also increase the testing matrix we need to cover and
>>>>>> increase the likelihood of kbuild breaks by an order of magnitude.
>>>>>>
>>>>> The testing matrix already exploded with the proliferation of
>>>>> supported features. If anything this reduces the test matrix problem.
>>>>> For instance, if we make a change to the core driver and functionality
>>>>> properly isolated there is a much better chance that this won't affect
>>>>> peripheral functionality and vice versa. It is just not feasible for
>>>>> us to test every combination of NIC features for every change being
>>>>> made.
>>>>>
>>>>
>>>> Yes for isolated features, but for base functionality, we need to test
>>>> it with all new device specific kconfig combinations on every patch!
>>>
>>> Sorry, but that is the price you need to pay for a feature rich device.
>>>
>>> On the subject of testing, I don't really see any indication in these
>>> patches on how patches are being tested. Also, there are patches that
>>> fix things without any mention of how to repro the problems. It is
>>
>> I Will do my best to provide more information in fixes commit
>> messages, Thanks for the input.
>>
>>> critical that we know IPv6 is tested as much or more than IPv4 (just
>>
>> For the record, for every IPv4 test in our automatic regression system
>> we have an IPv6 equivalent test,
>> not to mention IPv6-only directed tests.
>>
> Great to know. Is there a publicly available description of what
> specific tests are in the suite?
>
Nothing public, but i can collect some information and share it with
you if you wish.
but mostly traffic oriented tests and stress tests.
and configuration oriented tests:
- basic configuration stuff: IPv6 with MTU/ring/offloads changes, etc..
- Vxlan over IPv6, IPv6 over vxlan,
- and some more
>>> last week with hit yet another IPv6-only issue in an another upstream
>>> driver that should have been caught with a simple load test-- this
>>
>> Is there any IPv6-only functionality issues with mlx4/mlx5 that we
>> don't know about ?
>> If you do see any of those, please report them so we take the needed
>> corrective actions to fix them and cover them in our regression.
>>
> If we see them we will certainly let you know. This is not just
> functionality either, performance regression versus IPv4 should also
> be considered serious issues.
>
>>> really is not acceptable any more!). Please add a description of how
>>> patches were tested to commit logs.
>>>
>>
>> Acknowledge.
>>
>
> Thanks,
> Tom
>
>>> Tom
>>>
>>>> since a misplaced code inside or outside the correct ifdef
>>>> can easily go unnoticed and break functionality.
>>>>
>>>>>> One more thing, do we really need a device specific flag per feature
>>>>>> per vendor per device? can't we just use the same kconfig flag for
>>>>>> all drivers and if there is a more generic system wide flag that
>>>>>> covers the same feature
>>>>>> can't we just use it, for instance instead of
>>>>>> CONFIG_<DRIVER_NAME>_SRIOV why not use already existing CONFIG_PCI_IOV
>>>>>> for all drivers ?
>>>>>>
>>>>> That sounds good to me. We already have CONFIG_RFS_ACCEL and others
>>>>> that do that.
>>>>>
>>>>> Tom
>>>>>
>>>>>> Saeed.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Tom Herbert (4):
>>>>>>> mlx5: Make building eswitch configurable
>>>>>>> mlx5: Make building SR-IOV configurable
>>>>>>> mlx5: Make building tc hardware offload configurable
>>>>>>> mlx5: Make building vxlan hardware offload configurable
>>>>>>>
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 35 ++++++
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/Makefile | 16 ++-
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 129 ++++++++++++++++------
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 39 +++++--
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 4 +-
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/lag.c | 2 +
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 32 ++++--
>>>>>>> drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 6 +-
>>>>>>> 8 files changed, 205 insertions(+), 58 deletions(-)
>>>>>>>
>>>>>>> --
>>>>>>> 2.9.3
>>>>>>>
^ permalink raw reply
* Re: [PATCH] net: aquantia: atlantic: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-30 21:26 UTC (permalink / raw)
To: Pavel Belous; +Cc: netdev
In-Reply-To: <1485792782-5634-1-git-send-email-pavel.s.belous@gmail.com>
Hi Pavel,
On 1/30/17, Pavel Belous <pavel.s.belous@gmail.com> wrote:
> Hi Philippe,
>
> thanks you for your patch, it looks good.
> One improvement - could you please add support/advertising for TP?
>
>>+ supported |= SUPPORTED_Autoneg;
> need:
> supported |= SUPPORTED_TP;
>
>
>>+ advertising = (self->aq_nic_cfg.is_autoneg) ?
>> ADVERTISED_Autoneg : 0U;
>
> need:
> advertising |= ADVERTISED_TP;
>
Yes, of course, I add send, and I send a v2.
> Thank you.
Regards,
Philippe
^ permalink raw reply
* Re: [PATCH net-next 1/1] smc: some potential use after free bugs
From: David Miller @ 2017-01-30 21:38 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, dan.carpenter
In-Reply-To: <20170130095504.7940-2-ubraun@linux.vnet.ibm.com>
From: Ursula Braun <ubraun@linux.vnet.ibm.com>
Date: Mon, 30 Jan 2017 10:55:04 +0100
> From: Dan Carpenter <dan.carpenter@oracle.com>
>
> Say we got really unlucky and these failed on the last iteration, then
> it could lead to a use after free bug.
>
> Fixes: cd6851f30386 ("smc: remote memory buffers (RMBs)")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Applied, thank you.
^ permalink raw reply
* Re: pull-request: can 2017-01-30
From: David Miller @ 2017-01-30 21:39 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20170130101101.14150-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 30 Jan 2017 11:11:00 +0100
> this is a pull request of one patch.
>
> The patch is by Oliver Hartkopp and fixes the hrtimer/tasklet termination in
> bcm op removal.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH net] net/sched: cls_flower: Correct matching on ICMPv6 code
From: David Miller @ 2017-01-30 21:42 UTC (permalink / raw)
To: simon.horman; +Cc: dinan.gunawardena, netdev, oss-drivers
In-Reply-To: <1485789542-6346-1-git-send-email-simon.horman@netronome.com>
From: Simon Horman <simon.horman@netronome.com>
Date: Mon, 30 Jan 2017 16:19:02 +0100
> When matching on the ICMPv6 code ICMPV6_CODE rather than
> ICMPV4_CODE attributes should be used.
>
> This corrects what appears to be a typo.
>
> Sample usage:
>
> tc qdisc add dev eth0 ingress
> tc filter add dev eth0 protocol ipv6 parent ffff: flower \
> indev eth0 ip_proto icmpv6 type 128 code 0 action drop
>
> Without this change the code parameter above is effectively ignored.
>
> Fixes: 7b684884fbfa ("net/sched: cls_flower: Support matching on ICMP type and code")
> Signed-off-by: Simon Horman <simon.horman@netronome.com>
Applied, thanks a lot Simon.
^ permalink raw reply
* Re: [RFC PATCH 1/2] af_packet: direct dma for packet ineterface
From: John Fastabend @ 2017-01-30 21:51 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: bjorn.topel, jasowang, ast, alexander.duyck, john.r.fastabend,
netdev
In-Reply-To: <20170130191607.14d964e4@redhat.com>
On 17-01-30 10:16 AM, Jesper Dangaard Brouer wrote:
> On Fri, 27 Jan 2017 13:33:44 -0800 John Fastabend <john.fastabend@gmail.com> wrote:
>
>> This adds ndo ops for upper layer objects to request direct DMA from
>> the network interface into memory "slots". The slots must be DMA'able
>> memory given by a page/offset/size vector in a packet_ring_buffer
>> structure.
>>
>> The PF_PACKET socket interface can use these ndo_ops to do zerocopy
>> RX from the network device into memory mapped userspace memory. For
>> this to work drivers encode the correct descriptor blocks and headers
>> so that existing PF_PACKET applications work without any modification.
>> This only supports the V2 header formats for now. And works by mapping
>> a ring of the network device to these slots. Originally I used V2
>> header formats but this does complicate the driver a bit.
>>
>> V3 header formats added bulk polling via socket calls and timers
>> used in the polling interface to return every n milliseconds. Currently,
>> I don't see any way to support this in hardware because we can't
>> know if the hardware is in the middle of a DMA operation or not
>> on a slot. So when a timer fires I don't know how to advance the
>> descriptor ring leaving empty descriptors similar to how the software
>> ring works. The easiest (best?) route is to simply not support this.
>
> From a performance pov bulking is essential. Systems like netmap that
> also depend on transferring control between kernel and userspace,
> report[1] that they need at least bulking size 8, to amortize the overhead.
>
Bulking in general is not a problem it can be done on top of V2 implementation
without issue. Its the poll timer that seemed a bit clumsy to implement.
Looking at it again though I think we could do something if we cared to.
I'm not convinced we would gain much though.
Also v2 uses static buffer sizes so that every buffer is 2k or whatever
size the user configures. V3 allows the buffer size to be updated at
runtime which could be done in the drivers I suppose but would require
some ixgbe restructuring.
> [1] Figure 7, page 10, http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf
>
>
>> It might be worth creating a new v4 header that is simple for drivers
>> to support direct DMA ops with. I can imagine using the xdp_buff
>> structure as a header for example. Thoughts?
>
> Likely, but I would like that we do a measurement based approach. Lets
> benchmark with this V2 header format, and see how far we are from
> target, and see what lights-up in perf report and if it is something we
> can address.
Yep I'm hoping to get to this sometime this week.
>
>
>> The ndo operations and new socket option PACKET_RX_DIRECT work by
>> giving a queue_index to run the direct dma operations over. Once
>> setsockopt returns successfully the indicated queue is mapped
>> directly to the requesting application and can not be used for
>> other purposes. Also any kernel layers such as tc will be bypassed
>> and need to be implemented in the hardware via some other mechanism
>> such as tc offload or other offload interfaces.
>
> Will this also need to bypass XDP too?
There is nothing stopping this from working with XDP but why would
you want to run XDP here?
Dropping a packet for example is not really useful because its
already in memory user space can read. Modifying the packet seems
pointless user space can modify it. Maybe pushing a copy of the packet
to kernel stack is useful in some case? But I can't see where I would
want this.
>
> E.g. how will you support XDP_TX? AFAIK you cannot remove/detach a
> packet with this solution (and place it on a TX queue and wait for DMA
> TX completion).
>
This is something worth exploring. tpacket_v2 uses a fixed ring with
slots so all the pages are allocated and assigned to the ring at init
time. To xmit a packet in this case the user space application would
be required to leave the packet descriptor on the rx side pinned
until the tx side DMA has completed. Then it can unpin the rx side
and return it to the driver. This works if the TX/RX processing is
fast enough to keep up. For many things this is good enough.
For some work loads though this may not be sufficient. In which
case a tpacket_v4 would be useful that can push down a new set
of "slots" every n packets. Where n is sufficiently large to keep
the workload running. This is similar in many ways to virtio/vhost
interaction.
>
>> Users steer traffic to the selected queue using flow director,
>> tc offload infrastructure or via macvlan offload.
>>
>> The new socket option added to PF_PACKET is called PACKET_RX_DIRECT.
>> It takes a single unsigned int value specifying the queue index,
>>
>> setsockopt(sock, SOL_PACKET, PACKET_RX_DIRECT,
>> &queue_index, sizeof(queue_index));
>>
>> Implementing busy_poll support will allow userspace to kick the
>> drivers receive routine if needed. This work is TBD.
>>
>> To test this I hacked a hardcoded test into the tool psock_tpacket
>> in the selftests kernel directory here:
>>
>> ./tools/testing/selftests/net/psock_tpacket.c
>>
>> Running this tool opens a socket and listens for packets over
>> the PACKET_RX_DIRECT enabled socket. Obviously it needs to be
>> reworked to enable all the older tests and not hardcode my
>> interface before it actually gets released.
>>
>> In general this is a rough patch to explore the interface and
>> put something concrete up for debate. The patch does not handle
>> all the error cases correctly and needs to be cleaned up.
>>
>> Known Limitations (TBD):
>>
>> (1) Users are required to match the number of rx ring
>> slots with ethtool to the number requested by the
>> setsockopt PF_PACKET layout. In the future we could
>> possibly do this automatically.
>>
>> (2) Users need to configure Flow director or setup_tc
>> to steer traffic to the correct queues. I don't believe
>> this needs to be changed it seems to be a good mechanism
>> for driving directed dma.
>>
>> (3) Not supporting timestamps or priv space yet, pushing
>> a v4 packet header would resolve this nicely.
>>
>> (5) Only RX supported so far. TX already supports direct DMA
>> interface but uses skbs which is really not needed. In
>> the TX_RING case we can optimize this path as well.
>>
>> To support TX case we can do a similar "slots" mechanism and
>> kick operation. The kick could be a busy_poll like operation
>> but on the TX side. The flow would be user space loads up
>> n number of slots with packets, kicks tx busy poll bit, the
>> driver sends packets, and finally when xmit is complete
>> clears header bits to give slots back. When we have qdisc
>> bypass set today we already bypass the entire stack so no
>> paticular reason to use skb's in this case. Using xdp_buff
>> as a v4 packet header would also allow us to consolidate
>> driver code.
>>
>> To be done:
>>
>> (1) More testing and performance analysis
>> (2) Busy polling sockets
>> (3) Implement v4 xdp_buff headers for analysis
>> (4) performance testing :/ hopefully it looks good.
>
> Guess, I don't understand the details of the af_packet versions well
> enough, but can you explain to me, how userspace knows what slots it
> can read/fetch, and how it marks when it is complete/finished so the
> kernel knows it can reuse this slot?
>
At init time user space allocates a ring of buffers. Each buffer has
space to hold the packet descriptor + packet payload. The API gives this
to the driver to initialize DMA engine and assign addresses. At init
time all buffers are "owned" by the driver which is indicated by a status bit
in the descriptor header.
Userspace can spin on the status bit to know when the driver has handed
it to userspace. The driver will check the status bit before returning
the buffer to the hardware. Then a series of kicks are used to wake up
userspace (if its not spinning) and to wake up the driver if it is overrun
and needs to return buffers into its pool (not implemented yet). The
kick to wake up the driver could in a future v4 be used to push new
buffers to the driver if needed.
It seems to work reasonably well but the perf numbers will let us know
more.
.John
^ permalink raw reply
* Re: [PATCH net-next v7 0/3] Add support for the ethernet switch on the ESPRESSObin
From: David Miller @ 2017-01-30 21:53 UTC (permalink / raw)
To: gregory.clement
Cc: thomas.petazzoni, andrew, f.fainelli, jason, shjzhou,
vivien.didelot, netdev, linux-kernel, jpannell, nadavh, robertb,
kostap, dingwei, linux-arm-kernel, sebastian.hesselbarth
In-Reply-To: <cover.69cbc1ba8937d0fc442538f992d62fc88aa26dcc.1485804488.git-series.gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Mon, 30 Jan 2017 20:29:32 +0100
> This set of patches adds support for the Marvell Ethernet Topaz switch
> family (88E6141/88E6341) which is found on the ESPRESSObin. With this
> series the network is usable on this board.
>
> As usual, I rebased the series on the very last net-next/master. In
> this series there is no temperature support which need some patches
> form Andrew Lunn.
>
> As soon as Andrew Lunn will post the needed patch I will send a patch
> to enable the temperature support.
Series applied, thank you.
^ permalink raw reply
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
From: Kees Cook @ 2017-01-30 21:57 UTC (permalink / raw)
To: Shubham Bansal
Cc: Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening@lists.openwall.com, Russell King,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170130103853.GA34633@in3o.xyz>
On Mon, Jan 30, 2017 at 2:38 AM, Shubham Bansal
<illusionist.neo@gmail.com> wrote:
> Hi all,
>
> Please ignore last copy of this mail. Kernel mailing lists bounced my
> last mail back because of HTML content.
>
> Just starting a new thread with proper heading on the main kernel
> hardening and net-dev mailing list so that other people can be involved
> in this. Please don't take this as a personal mail.
>
> I am working on conversion of arm32 cBPF into eBPF JIT. I wanted some
> help, regarding understanding of kernel code, from the dev available on
> the mailing list. If you look at the ./arch/arm/net/bpf_jit_32.c code,
> you will see jit_ctx structure. If anybody could help me understand what
> each fields of this structure represent then it would be great.
>
> Also, currently I am mapping the eBPF registers to arm 32 bit registers
> in the following way.
>
>> static const int bpf2a32[] = {
>>
>> /* return value from in-kernel function, and exit value from
>> eBPF
>> */
>> [BPF_REG_0] = ARM_R0,
>>
>> /* arguments from eBPF program to in-kernel function */
>>
>> [BPF_REG_1] = ARM_R1,
>>
>> [BPF_REG_2] = ARM_R2,
>>
>> [BPF_REG_3] = ARM_R3,
>>
>> [BPF_REG_4] = ARM_R4,
>>
>> [BPF_REG_5] = ARM_R5,
>>
>> /* callee saved registers that in-kernel function will
>> preserve */
>>
>> [BPF_REG_6] = ARM_R6,
>>
>> [BPF_REG_7] = ARM_R7,
>>
>> [BPF_REG_8] = ARM_R8,
>>
>> [BPF_REG_9] = ARM_R9,
>>
>> /* Read only Frame Pointer to access Stack */
>>
>> [BPF_REG_FP] = ARM_FP,
>>
>> /* Temperory Register for internal BPF JIT */
>>
>> [TMP_REG_1] = ARM_R11,
>>
>> /* temporary register for blinding constants */
>>
>> [BPF_REG_AX] = ARM_R10,
>>
>> };
>
> But I have some question if anybody could help with those.
>
> 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
> registers with 32 bit arm registers which looks wrong to me. Do anybody
> have some idea about how to map eBPF->arm 32 bit registers ?
I was going to say "look at the x86 32-bit implementation." ... But
there isn't one. :( I'm going to guess that there isn't a very good
answer here. I assume you'll have to build some kind of stack scratch
space to load/save.
> 2.) Also, is my current mapping good enough to make the JIT fast enough ?
> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> its instructions with native instructions.
I don't know -- it might be tricky with needing to deal with 64-bit
registers. But if you can make it faster than the non-JIT, it should
be a win. :) Yay assembly.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [RFC PATCH 0/2] rx zero copy interface for af_packet
From: David Miller @ 2017-01-30 22:02 UTC (permalink / raw)
To: john.fastabend
Cc: bjorn.topel, jasowang, ast, alexander.duyck, brouer,
john.r.fastabend, netdev
In-Reply-To: <20170127213132.14162.82951.stgit@john-Precision-Tower-5810>
From: John Fastabend <john.fastabend@gmail.com>
Date: Fri, 27 Jan 2017 13:33:20 -0800
> This is an experimental implementation of rx zero copy for af_packet.
> Its a bit rough and likely has errors but the plan is to clean it up
> over the next few months.
>
> And seeing I said I would post it in another thread a few days back
> here it is.
>
> Comments welcome and use at your own risk.
The one thing I do like about this is the fact that the user cannot
access the DMA length and DMA address in the hardware descriptors.
So, at least in that sense, the kernel is still providing the
necessary protection between the user and the hardware device.
^ permalink raw reply
* [PATCH v2] net: aquantia: atlantic: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2017-01-30 22:04 UTC (permalink / raw)
To: Alexander.Loktionov, Pavel.Belous, davem, Dmitry.Bezrukov,
vomlehn
Cc: netdev, linux-kernel, Philippe Reynes
The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.
As I don't have the hardware, I'd be very pleased if
someone may test this patch.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
---
Changelog:
v2:
- add support and advertise for TP
.../net/ethernet/aquantia/atlantic/aq_ethtool.c | 23 +++++----
drivers/net/ethernet/aquantia/atlantic/aq_nic.c | 51 +++++++++++++-------
drivers/net/ethernet/aquantia/atlantic/aq_nic.h | 6 ++-
3 files changed, 49 insertions(+), 31 deletions(-)
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
index c5b025e..a761e91 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
@@ -35,24 +35,25 @@ static u32 aq_ethtool_get_link(struct net_device *ndev)
return ethtool_op_get_link(ndev);
}
-static int aq_ethtool_get_settings(struct net_device *ndev,
- struct ethtool_cmd *cmd)
+static int aq_ethtool_get_link_ksettings(struct net_device *ndev,
+ struct ethtool_link_ksettings *cmd)
{
struct aq_nic_s *aq_nic = netdev_priv(ndev);
- aq_nic_get_link_settings(aq_nic, cmd);
- ethtool_cmd_speed_set(cmd, netif_carrier_ok(ndev) ?
- aq_nic_get_link_speed(aq_nic) : 0U);
+ aq_nic_get_link_ksettings(aq_nic, cmd);
+ cmd->base.speed = netif_carrier_ok(ndev) ?
+ aq_nic_get_link_speed(aq_nic) : 0U;
return 0;
}
-static int aq_ethtool_set_settings(struct net_device *ndev,
- struct ethtool_cmd *cmd)
+static int
+aq_ethtool_set_link_ksettings(struct net_device *ndev,
+ const struct ethtool_link_ksettings *cmd)
{
struct aq_nic_s *aq_nic = netdev_priv(ndev);
- return aq_nic_set_link_settings(aq_nic, cmd);
+ return aq_nic_set_link_ksettings(aq_nic, cmd);
}
/* there "5U" is number of queue[#] stats lines (InPackets+...+InErrors) */
@@ -248,8 +249,6 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_link = aq_ethtool_get_link,
.get_regs_len = aq_ethtool_get_regs_len,
.get_regs = aq_ethtool_get_regs,
- .get_settings = aq_ethtool_get_settings,
- .set_settings = aq_ethtool_set_settings,
.get_drvinfo = aq_ethtool_get_drvinfo,
.get_strings = aq_ethtool_get_strings,
.get_rxfh_indir_size = aq_ethtool_get_rss_indir_size,
@@ -257,5 +256,7 @@ static int aq_ethtool_get_rxnfc(struct net_device *ndev,
.get_rxfh = aq_ethtool_get_rss,
.get_rxnfc = aq_ethtool_get_rxnfc,
.get_sset_count = aq_ethtool_get_sset_count,
- .get_ethtool_stats = aq_ethtool_stats
+ .get_ethtool_stats = aq_ethtool_stats,
+ .get_link_ksettings = aq_ethtool_get_link_ksettings,
+ .set_link_ksettings = aq_ethtool_set_link_ksettings,
};
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
index 84bb441..bed25ab 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -734,50 +734,65 @@ void aq_nic_get_stats(struct aq_nic_s *self, u64 *data)
(void)err;
}
-void aq_nic_get_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd)
+void aq_nic_get_link_ksettings(struct aq_nic_s *self,
+ struct ethtool_link_ksettings *cmd)
{
- cmd->port = PORT_TP;
- cmd->transceiver = XCVR_EXTERNAL;
+ u32 supported, advertising;
+
+ cmd->base.port = PORT_TP;
/* This driver supports only 10G capable adapters, so DUPLEX_FULL */
- cmd->duplex = DUPLEX_FULL;
- cmd->autoneg = self->aq_nic_cfg.is_autoneg;
+ cmd->base.duplex = DUPLEX_FULL;
+ cmd->base.autoneg = self->aq_nic_cfg.is_autoneg;
+
+ ethtool_convert_link_mode_to_legacy_u32(&supported,
+ cmd->link_modes.supported);
+ ethtool_convert_link_mode_to_legacy_u32(&advertising,
+ cmd->link_modes.advertising);
- cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
+ supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_10G) ?
ADVERTISED_10000baseT_Full : 0U;
- cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
+ supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_1G) ?
ADVERTISED_1000baseT_Full : 0U;
- cmd->supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?
+ supported |= (self->aq_hw_caps.link_speed_msk & AQ_NIC_RATE_100M) ?
ADVERTISED_100baseT_Full : 0U;
- cmd->supported |= self->aq_hw_caps.flow_control ? SUPPORTED_Pause : 0;
- cmd->supported |= SUPPORTED_Autoneg;
+ supported |= self->aq_hw_caps.flow_control ? SUPPORTED_Pause : 0;
+ supported |= SUPPORTED_Autoneg;
+ supported |= SUPPORTED_TP;
- cmd->advertising = (self->aq_nic_cfg.is_autoneg) ?
+ advertising = (self->aq_nic_cfg.is_autoneg) ?
ADVERTISED_Autoneg : 0U;
- cmd->advertising |=
+ advertising |=
(self->aq_nic_cfg.link_speed_msk & AQ_NIC_RATE_10G) ?
ADVERTISED_10000baseT_Full : 0U;
- cmd->advertising |=
+ advertising |=
(self->aq_nic_cfg.link_speed_msk & AQ_NIC_RATE_1G) ?
ADVERTISED_1000baseT_Full : 0U;
- cmd->advertising |=
+ advertising |=
(self->aq_nic_cfg.link_speed_msk & AQ_NIC_RATE_100M) ?
ADVERTISED_100baseT_Full : 0U;
- cmd->advertising |= (self->aq_nic_cfg.flow_control) ?
+ advertising |= (self->aq_nic_cfg.flow_control) ?
ADVERTISED_Pause : 0U;
+ advertising |= ADVERTISED_TP;
+
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+ supported);
+ ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+ advertising);
}
-int aq_nic_set_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd)
+int aq_nic_set_link_ksettings(struct aq_nic_s *self,
+ const struct ethtool_link_ksettings *cmd)
{
u32 speed = 0U;
u32 rate = 0U;
int err = 0;
- if (cmd->autoneg == AUTONEG_ENABLE) {
+ if (cmd->base.autoneg == AUTONEG_ENABLE) {
rate = self->aq_hw_caps.link_speed_msk;
self->aq_nic_cfg.is_autoneg = true;
} else {
- speed = ethtool_cmd_speed(cmd);
+ speed = cmd->base.speed;
switch (speed) {
case SPEED_100:
diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
index 055e2cd..7fc2a5e 100644
--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.h
@@ -99,8 +99,10 @@ void aq_nic_set_tx_ring(struct aq_nic_s *self, unsigned int idx,
int aq_nic_set_packet_filter(struct aq_nic_s *self, unsigned int flags);
int aq_nic_set_multicast_list(struct aq_nic_s *self, struct net_device *ndev);
unsigned int aq_nic_get_link_speed(struct aq_nic_s *self);
-void aq_nic_get_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd);
-int aq_nic_set_link_settings(struct aq_nic_s *self, struct ethtool_cmd *cmd);
+void aq_nic_get_link_ksettings(struct aq_nic_s *self,
+ struct ethtool_link_ksettings *cmd);
+int aq_nic_set_link_ksettings(struct aq_nic_s *self,
+ const struct ethtool_link_ksettings *cmd);
struct aq_nic_cfg_s *aq_nic_get_cfg(struct aq_nic_s *self);
u32 aq_nic_get_fw_version(struct aq_nic_s *self);
int aq_nic_change_pm_state(struct aq_nic_s *self, pm_message_t *pm_msg);
--
1.7.4.4
^ permalink raw reply related
* [PATCH] ipv6: fix flow labels when the traffic class is non-0
From: Dimitris Michailidis @ 2017-01-30 22:09 UTC (permalink / raw)
To: davem, tom; +Cc: netdev, edumazet, Dimitris Michailidis
ip6_make_flowlabel() determines the flow label for IPv6 packets. It's
supposed to be passed a flow label, which it returns as is if non-0 and
in some other cases, otherwise it calculates a new value.
The problem is callers often pass a flowi6.flowlabel, which may also
contain traffic class bits. If the traffic class is non-0
ip6_make_flowlabel() mistakes the non-0 it gets as a flow label and
returns the whole thing. Thus it can return a 'flow label' longer than
20b and the low 20b of that is typically 0 resulting in packets with 0
label. Moreover, different packets of a flow may be labeled differently.
For a TCP flow with ECN non-payload and payload packets get different
labels as exemplified by this pair of consecutive packets:
(pure ACK)
Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 0001 1100 1110 0100 1001 = Flow Label: 0x1ce49
Payload Length: 32
Next Header: TCP (6)
(payload)
Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
0110 .... = Version: 6
.... 0000 0010 .... .... .... .... .... = Traffic Class: 0x02 (DSCP: CS0, ECN: ECT(0))
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..10 .... .... .... .... .... = Explicit Congestion Notification: ECN-Capable Transport codepoint '10' (2)
.... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
Payload Length: 688
Next Header: TCP (6)
This patch allows ip6_make_flowlabel() to be passed more than just a
flow label and has it extract the part it really wants. This was simpler
than modifying the callers. With this patch packets like the above become
Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
0110 .... = Version: 6
.... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
.... .... .... 1010 1111 1010 0101 1110 = Flow Label: 0xafa5e
Payload Length: 32
Next Header: TCP (6)
Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
0110 .... = Version: 6
.... 0000 0010 .... .... .... .... .... = Traffic Class: 0x02 (DSCP: CS0, ECN: ECT(0))
.... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
.... .... ..10 .... .... .... .... .... = Explicit Congestion Notification: ECN-Capable Transport codepoint '10' (2)
.... .... .... 1010 1111 1010 0101 1110 = Flow Label: 0xafa5e
Payload Length: 688
Next Header: TCP (6)
Signed-off-by: Dimitris Michailidis <dmichail@google.com>
---
include/net/ipv6.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 7afe991e900e..dbf0abba33b8 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -776,6 +776,11 @@ static inline __be32 ip6_make_flowlabel(struct net *net, struct sk_buff *skb,
{
u32 hash;
+ /* @flowlabel may include more than a flow label, eg, the traffic class.
+ * Here we want only the flow label value.
+ */
+ flowlabel &= IPV6_FLOWLABEL_MASK;
+
if (flowlabel ||
net->ipv6.sysctl.auto_flowlabels == IP6_AUTO_FLOW_LABEL_OFF ||
(!autolabel &&
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* Re: [PATCH] ipv6: fix flow labels when the traffic class is non-0
From: Eric Dumazet @ 2017-01-30 22:23 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: David Miller, Tom Herbert, netdev
In-Reply-To: <20170130220942.19105-1-dmichail@google.com>
On Mon, Jan 30, 2017 at 2:09 PM, Dimitris Michailidis
<dmichail@google.com> wrote:
> ip6_make_flowlabel() determines the flow label for IPv6 packets. It's
> supposed to be passed a flow label, which it returns as is if non-0 and
> in some other cases, otherwise it calculates a new value.
>
> The problem is callers often pass a flowi6.flowlabel, which may also
> contain traffic class bits.
Do you have an idea which commit added this bug Dimitris ?
Thanks !
^ permalink raw reply
* [PATCH] rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink
From: Theuns Verwoerd @ 2017-01-30 22:28 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David Ahern
rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink
Allow a master interface to be specified as one of the parameters when
creating a new interface via rtnl_newlink. Previously this would
require invoking interface creation, waiting for it to complete, and
then separately binding that new interface to a master.
In particular, this is used when creating a macvlan child interface for
VRRP in a VRF configuration, allowing the interface creator to specify
directly what master interface should be inherited by the child,
without having to deal with asynchronous complications and potential
race conditions.
Signed-off-by: Theuns Verwoerd <theuns.verwoerd@alliedtelesis.co.nz>
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 75e3ea7bda08..a24719c98238 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2571,7 +2571,7 @@ static int rtnl_newlink(struct sk_buff *skb,
struct nlmsghdr *nlh)
return -ENODEV;
}
- if (tb[IFLA_MAP] || tb[IFLA_MASTER] || tb[IFLA_PROTINFO])
+ if (tb[IFLA_MAP] || tb[IFLA_PROTINFO])
return -EOPNOTSUPP;
if (!ops) {
@@ -2653,6 +2653,11 @@ static int rtnl_newlink(struct sk_buff *skb,
struct nlmsghdr *nlh)
if (err < 0)
goto out_unregister;
}
+ if (tb[IFLA_MASTER]) {
+ err = do_set_master(dev,
nla_get_u32(tb[IFLA_MASTER]));
+ if (err)
+ goto out_unregister;
+ }
out:
if (link_net)
put_net(link_net);
^ permalink raw reply related
* Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()
From: Florian Fainelli @ 2017-01-30 22:46 UTC (permalink / raw)
To: Greg KH
Cc: Andrew Lunn, Jason Cooper, Vivien Didelot, netdev,
Russell King - ARM Linux, open list, Gregory Clement,
David S. Miller, moderated list:ARM SUB-ARCHITECTURES,
Sebastian Hesselbarth
In-Reply-To: <20170125212500.GA6052@kroah.com>
On 01/25/2017 01:25 PM, Greg KH wrote:
> On Tue, Jan 24, 2017 at 10:59:15AM -0800, Florian Fainelli wrote:
>> On 01/19/2017 10:12 AM, Florian Fainelli wrote:
>>>
>>> Back to the actual code that triggered this discussion, the whole
>>> purpose is just a safeguard. Given a device reference, we can assume
>>> that it is indeed the backing device for a net_device, and we could do a
>>> to_net_device() right away (and crash if someone did not write correct
>>> platform_data structures), or, by walking the device tree (the device
>>> driver model one) we can make sure it does belong in the proper class
>>> and this is indeed what we think it is.
>>
>> Greg, did Russell's explanation clarify things, or do you still think
>> this is completely bogus and we need to re design the whole thing?
>>
>> Just asking so I can try to resubmit just the preparatory parts or just
>> the whole thing.
>
> Sorry, I haven't gotten back to this, it's lower on my list. Should try
> to get to it tomorrow...
Greg, please give some feedback here, I can only produce new patches as
fast as I am given feedback, and I would really hate to miss the 4.11
merge window because we have been sleeping on this. If there is a need
to clarify things, I will be more than happy to try to provide information.
Thank you!
--
Florian
^ permalink raw reply
* Re: [PATCH] rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink
From: Stephen Hemminger @ 2017-01-30 22:44 UTC (permalink / raw)
To: Theuns Verwoerd; +Cc: netdev@vger.kernel.org, David Ahern
In-Reply-To: <38fc316c-a522-a8ca-d029-25fa5335a954@alliedtelesis.co.nz>
On Mon, 30 Jan 2017 22:28:05 +0000
Theuns Verwoerd <Theuns.Verwoerd@alliedtelesis.co.nz> wrote:
> rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink
>
> Allow a master interface to be specified as one of the parameters when
> creating a new interface via rtnl_newlink. Previously this would
> require invoking interface creation, waiting for it to complete, and
> then separately binding that new interface to a master.
>
> In particular, this is used when creating a macvlan child interface for
> VRRP in a VRF configuration, allowing the interface creator to specify
> directly what master interface should be inherited by the child,
> without having to deal with asynchronous complications and potential
> race conditions.
>
> Signed-off-by: Theuns Verwoerd <theuns.verwoerd@alliedtelesis.co.nz>
>
> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
> index 75e3ea7bda08..a24719c98238 100644
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
> @@ -2571,7 +2571,7 @@ static int rtnl_newlink(struct sk_buff *skb,
> struct nlmsghdr *nlh)
> return -ENODEV;
> }
>
> - if (tb[IFLA_MAP] || tb[IFLA_MASTER] || tb[IFLA_PROTINFO])
> + if (tb[IFLA_MAP] || tb[IFLA_PROTINFO])
> return -EOPNOTSUPP;
>
> if (!ops) {
> @@ -2653,6 +2653,11 @@ static int rtnl_newlink(struct sk_buff *skb,
> struct nlmsghdr *nlh)
> if (err < 0)
> goto out_unregister;
> }
> + if (tb[IFLA_MASTER]) {
> + err = do_set_master(dev,
> nla_get_u32(tb[IFLA_MASTER]));
> + if (err)
> + goto out_unregister;
> + }
> out:
> if (link_net)
> put_net(link_net);
Your mailer is reformatting text which corrupts patches.
Please adjust your client settings, or use a different mail system.
^ permalink raw reply
* [PATCH] rtnetlink: Handle IFLA_MASTER parameter when processing rtnl_newlink
From: Theuns Verwoerd @ 2017-01-30 23:23 UTC (permalink / raw)
To: netdev; +Cc: dsa, Theuns Verwoerd
Allow a master interface to be specified as one of the parameters when
creating a new interface via rtnl_newlink. Previously this would
require invoking interface creation, waiting for it to complete, and
then separately binding that new interface to a master.
In particular, this is used when creating a macvlan child interface for
VRRP in a VRF configuration, allowing the interface creator to specify
directly what master interface should be inherited by the child,
without having to deal with asynchronous complications and potential
race conditions.
Signed-off-by: Theuns Verwoerd <theuns.verwoerd@alliedtelesis.co.nz>
---
net/core/rtnetlink.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 75e3ea7bda08..a24719c98238 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2571,7 +2571,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh)
return -ENODEV;
}
- if (tb[IFLA_MAP] || tb[IFLA_MASTER] || tb[IFLA_PROTINFO])
+ if (tb[IFLA_MAP] || tb[IFLA_PROTINFO])
return -EOPNOTSUPP;
if (!ops) {
@@ -2653,6 +2653,11 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh)
if (err < 0)
goto out_unregister;
}
+ if (tb[IFLA_MASTER]) {
+ err = do_set_master(dev, nla_get_u32(tb[IFLA_MASTER]));
+ if (err)
+ goto out_unregister;
+ }
out:
if (link_net)
put_net(link_net);
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox