* Re: [PATCH net-next] net: marvell: mvpp2: clear flow control modes in 10G mode
From: David Miller @ 2019-02-09 17:34 UTC (permalink / raw)
To: rmk+kernel
Cc: antoine.tenart, maxime.chevallier, baruch, sven.auhagen, netdev
In-Reply-To: <E1gsV9X-00047r-QY@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Sat, 09 Feb 2019 16:06:51 +0000
> When mvpp2 configures the flow control modes in mvpp2_xlg_config() for
> 10G mode, it only ever set the flow control enable bits. There is no
> mechanism to clear these bits, which means that userspace is unable to
> use standard APIs to disable flow control (the only way is to poke the
> register directly.)
>
> Fix the missing bit clearance to allow flow control to be disabled.
> This means that, by default, as there is no negotiation in 10G modes
> with mvpp2, flow control is now disabled rather than being rx-only.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] net: mvpp2: clear flow control modes in 10G mode
From: David Miller @ 2019-02-09 17:34 UTC (permalink / raw)
To: linux; +Cc: antoine.tenart, maxime.chevallier, baruch, sven.auhagen, netdev
In-Reply-To: <20190209160708.e7o5wlcj2gt3f7cy@shell.armlinux.org.uk>
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Sat, 9 Feb 2019 16:07:08 +0000
> Please ignore this one - subject line is not correct. Thanks.
Aha, ok I'll apply the correct one.
^ permalink raw reply
* Re: [PATCH] net: hso: do not unregister if not registered
From: David Miller @ 2019-02-09 17:35 UTC (permalink / raw)
To: tuba; +Cc: netdev
In-Reply-To: <89a423a522834affadda4aaf7ab4d333@exmbxprd18.ad.ufl.edu>
From: "Yavuz, Tuba" <tuba@ece.ufl.edu>
Date: Sat, 9 Feb 2019 16:24:20 +0000
>
>
> On an error path inside the hso_create_net_device function of the hso
> driver, hso_free_net_device gets called. This causes potentially a
> negative reference count in the net device if register_netdev has not
> been called yet as hso_free_net_device calls unregister_netdev
> regardless. I think the driver should distinguish these cases and call
> unregister_netdev only if register_netdev has been called.
>
> Signed-off-by: Tuba Yavuz <tuba@ece.ufl.edu>
Your patch is still corrupted.
Email this patch to yourself and try to apply it to a source tree.
You will see that it won't work.
Please do not post this patch again until you have fixed this problem
and have also successfully applied a patch you have test emailed to
yourself.
Thanks.
^ permalink raw reply
* Re: TC stats / hw offload question
From: Jamal Hadi Salim @ 2019-02-09 17:39 UTC (permalink / raw)
To: Edward Cree, netdev
Cc: Jiri Pirko, Cong Wang, Or Gerlitz, Andy Gospodarek, PJ Waskiewicz,
Anjali Singhai Jain, Jakub Kicinski
In-Reply-To: <70d77198-42fd-838a-d352-2647e7cad4d6@solarflare.com>
On 2019-02-08 5:26 a.m., Edward Cree wrote:
> On 06/02/19 02:20, Jamal Hadi Salim wrote:
>> tc match using flower blah \
>> action vlan push tag ... \
>> action redirect to egress of eth0
>>
>> And you submited a packet of size x bytes,
>> then the "match" would record x bytes.
>
> Sorry, where would it record that?
Sorry - that was hypothetical on my part. We dont
record the bytes in the classifier. We do (on some
classifiers) record hit counts, so we can see how many
times a lookup on a specific filter happened and how
many times that lookup resulted in a match.
See u32 (or a few others Cong has been updating
recently).
> I can't find any stats counters on
> the "match" either in the software path or the offload API.
Hasnt been necessary thus far.
Is your end goal to match and count?
Most hardware has stats/counters as a separate table.
Assuming yours does as well, then if all you want was
to just match and accept, then you would add a filter
with an accept/ok. i.e something along the lines of:
tc match using flower blah \
action ok index 12345
The "action index" field can be used to map to a counter
table index in hardware. Note if you dont explicitly
specify the index, the kernel (and in this case h/w)
issues one for you.
>> the "vlan action" would record x bytes.
>> the "redirect" would record size x+vlaninfo bytes
>> the egress of eth0 would recorr x+vlaninfo bytes
> Am I right in thinking that offloaded counters don't do that? As far
> as I can tell, the drivers with flower offload all use
> tcf_exts_stats_update() which takes a single 'bytes' count and adds
> it to all the actions. (Presumably this is pre-edit length.)
On the pre/post edit, perhaps some of the hardware
owners could chime in +Ccing a few.
To the tcf_exts_stats_update():
Note, most people interested in h/w offload will choose to skip
sw (explicitly defined when you add a rule).
The update synchronizes the hardware stats/counters
to the kernel - so when you dump the policies in such a setup
you are seeing what is reflected in hardware.
cheers,
jamal
PS: I have to say just keeping one counter is at times
insufficient. Example, the policer records how many bytes
were seen, not how many bytes were allowed through.
For tunnels, it is easy to compute post-edit size because
you can easily compute later the added/removed bytes.
^ permalink raw reply
* Re: [PATCH net-next 02/16] mlxsw: spectrum: Check bridge flags during prepare phase
From: Jiri Pirko @ 2019-02-09 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-3-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:34AM CET, f.fainelli@gmail.com wrote:
>In preparation for getting rid of switchdev_port_attr_get(), have mlxsw
>check for the bridge flags being set through switchdev_port_attr_set()
>with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 03/16] staging: fsl-dpaa2: ethsw: Check bridge port flags during set
From: Jiri Pirko @ 2019-02-09 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-4-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:35AM CET, f.fainelli@gmail.com wrote:
>In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
>have ethsw check that the bridge port flags that are being set are
>supported.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 04/16] net: dsa: Add setter for SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS
From: Jiri Pirko @ 2019-02-09 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-5-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:36AM CET, f.fainelli@gmail.com wrote:
>In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
>add support for a function that processes the
>SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute and returns not supported
>for any flag set, since DSA does not currently support toggling those
>bridge port attributes (yet).
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 05/16] rocker: Check bridge flags during prepare phase
From: Jiri Pirko @ 2019-02-09 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-6-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:37AM CET, f.fainelli@gmail.com wrote:
>In preparation for getting rid of switchdev_port_attr_get(), have rocker
>check for the bridge flags being set through switchdev_port_attr_set()
>with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 06/16] net: bridge: Stop calling switchdev_port_attr_get()
From: Jiri Pirko @ 2019-02-09 17:48 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-7-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:38AM CET, f.fainelli@gmail.com wrote:
>Now that all switchdev drivers have been converted to checking the
>bridge port flags during the prepare phase of the
>switchdev_port_attr_set(), we can move straight to trying to set the
>desired flag through SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 07/16] net: Remove SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT
From: Jiri Pirko @ 2019-02-09 17:49 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-8-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:39AM CET, f.fainelli@gmail.com wrote:
>Now that we have converted the bridge code and the drivers to check for
>bridge port(s) flags at the time we try to set them, there is no need
>for a get() -> set() sequence anymore and
>SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 08/16] net: Get rid of switchdev_port_attr_get()
From: Jiri Pirko @ 2019-02-09 18:15 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-9-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:40AM CET, f.fainelli@gmail.com wrote:
>With the bridge no longer calling switchdev_port_attr_get() to obtain
>the supported bridge port flags from a driver but instead trying to set
>the bridge port flags directly and relying on driver to reject
>unsupported configurations, we can effectively get rid of
>switchdev_port_attr_get() entirely since this was the only place where
>it was called.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 09/16] switchdev: Add SWITCHDEV_PORT_ATTR_SET
From: Jiri Pirko @ 2019-02-09 18:18 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-10-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:41AM CET, f.fainelli@gmail.com wrote:
>In preparation for allowing switchdev enabled drivers to veto specific
>attribute settings from within the context of the caller, introduce a
>new switchdev notifier type for port attributes.
>
>Suggested-by: Ido Schimmel <idosch@mellanox.com>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>---
> include/net/switchdev.h | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
>diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>index 96cd3e795f7f..4c5f7e5430cf 100644
>--- a/include/net/switchdev.h
>+++ b/include/net/switchdev.h
>@@ -141,6 +141,8 @@ enum switchdev_notifier_type {
> SWITCHDEV_VXLAN_FDB_ADD_TO_DEVICE,
> SWITCHDEV_VXLAN_FDB_DEL_TO_DEVICE,
> SWITCHDEV_VXLAN_FDB_OFFLOADED,
>+
>+ SWITCHDEV_PORT_ATTR_SET, /* Blocking. */
This is not UAPI. You can put it next to SWITCHDEV_PORT_OBJ_ADD and
SWITCHDEV_PORT_OBJ_DEL. Up to you.
With or without that:
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next 10/16] rocker: Handle SWITCHDEV_PORT_ATTR_SET
From: Jiri Pirko @ 2019-02-09 18:21 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209003248.31088-11-f.fainelli@gmail.com>
Sat, Feb 09, 2019 at 01:32:42AM CET, f.fainelli@gmail.com wrote:
>Following patches will change the way we communicate getting or setting
Just "setting", no "getting".
>a port's attribute and use a blocking notifier to perform those tasks.
>
>Prepare rocker to support receiving notifier events targeting
>SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
>rocker_port_attr_set call.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>---
> drivers/net/ethernet/rocker/rocker_main.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
>diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
>index ff3f14504f4f..f10e4888ecff 100644
>--- a/drivers/net/ethernet/rocker/rocker_main.c
>+++ b/drivers/net/ethernet/rocker/rocker_main.c
>@@ -2811,6 +2811,24 @@ rocker_switchdev_port_obj_event(unsigned long event, struct net_device *netdev,
> return notifier_from_errno(err);
> }
>
>+static int
>+rocker_switchdev_port_attr_event(unsigned long event, struct net_device *netdev,
>+ struct switchdev_notifier_port_attr_info
>+ *port_attr_info)
>+{
>+ int err = -EOPNOTSUPP;
>+
>+ switch (event) {
>+ case SWITCHDEV_PORT_ATTR_SET:
Do you expect some other event to be handled in
rocker_switchdev_port_attr_event()? Because you have SWITCHDEV_PORT_ATTR_SET
selected in case here and in rocker_switchdev_blocking_event.
Perhaps you can rename rocker_switchdev_port_attr_event() to
rocker_switchdev_port_attr_set_event() and avoid this switchcase.
>+ err = rocker_port_attr_set(netdev, port_attr_info->attr,
>+ port_attr_info->trans);
>+ break;
>+ }
>+
>+ port_attr_info->handled = true;
>+ return notifier_from_errno(err);
>+}
>+
> static int rocker_switchdev_blocking_event(struct notifier_block *unused,
> unsigned long event, void *ptr)
> {
>@@ -2823,6 +2841,8 @@ static int rocker_switchdev_blocking_event(struct notifier_block *unused,
> case SWITCHDEV_PORT_OBJ_ADD:
> case SWITCHDEV_PORT_OBJ_DEL:
> return rocker_switchdev_port_obj_event(event, dev, ptr);
>+ case SWITCHDEV_PORT_ATTR_SET:
>+ return rocker_switchdev_port_attr_event(event, dev, ptr);
> }
>
> return NOTIFY_DONE;
>--
>2.17.1
>
^ permalink raw reply
* Re: [PATCH net-next 10/16] rocker: Handle SWITCHDEV_PORT_ATTR_SET
From: Jiri Pirko @ 2019-02-09 18:24 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <20190209182147.GQ2353@nanopsycho>
Sat, Feb 09, 2019 at 07:21:47PM CET, jiri@resnulli.us wrote:
[...]
>>+static int
>>+rocker_switchdev_port_attr_event(unsigned long event, struct net_device *netdev,
>>+ struct switchdev_notifier_port_attr_info
>>+ *port_attr_info)
>>+{
>>+ int err = -EOPNOTSUPP;
>>+
>>+ switch (event) {
>>+ case SWITCHDEV_PORT_ATTR_SET:
>
>Do you expect some other event to be handled in
>rocker_switchdev_port_attr_event()? Because you have SWITCHDEV_PORT_ATTR_SET
>selected in case here and in rocker_switchdev_blocking_event.
>Perhaps you can rename rocker_switchdev_port_attr_event() to
>rocker_switchdev_port_attr_set_event() and avoid this switchcase.
Same comment applies on next 4 patches.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Add support for asking the PHY its abilities
From: Heiner Kallweit @ 2019-02-09 19:12 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190209163554.GB30856@lunn.ch>
On 09.02.2019 17:35, Andrew Lunn wrote:
> On Sat, Feb 09, 2019 at 03:24:47PM +0100, Heiner Kallweit wrote:
>> From: Andrew Lunn <andrew@lunn.ch>
>> Add support for runtime determination of what the PHY supports, by
>> adding a new function to the phy driver. The get_features call should
>> set the phydev->supported member with the features the PHY supports.
>> It is only called if phydrv->features is NULL.
>>
>> This requires minor changes to pause. The PHY driver should not set
>> pause abilities, except for when it has odd cause capabilities, e.g.
>> pause cannot be disabled. With this change, phydev->supported already
>> contains the drivers abilities, including pause. So rather than
>> considering phydrv->features, look at the phydev->supported, and
>> enable pause if neither of the pause bits are already set.
>
> Hi Heiner
>
> Ah, cool, these are the patches i was asking for, when you asked
> about splitting Maxime's patches. There is one more in my tree which
> converts the marvell10g to using this. I think that should be posted
> as well. It makes it clear how this should be used, and it replaces
> one of the patches in Maxime's set.
>
I know, it's patch 15 in your series ;) And I'm aware that usually new
core functionality is acceptable only if it comes together with a user,
to avoid having billions of orphaned good ideas in the code.
I focused on the core here to not get lost in all the new stuff, and to
provide Maxime with some direction for adjusting his series.
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> [hkallweit1@gmail.com: fixed small checkpatch complaint in one comment]
>
> Thanks.
>
> Andrew
>
Heiner
^ permalink raw reply
* Re: [PATCH][next] can: at91_can: mark expected switch fall-throughs
From: Sergei Shtylyov @ 2019-02-09 19:17 UTC (permalink / raw)
To: Gustavo A. R. Silva, Wolfgang Grandegger, Marc Kleine-Budde,
David S. Miller, Nicolas Ferre, Alexandre Belloni,
Ludovic Desroches
Cc: linux-can, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <8402d6f6-dff1-eb99-3bd1-051b4f6f24f0@cogentembedded.com>
On 02/08/2019 09:55 PM, Sergei Shtylyov wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Notice that, in this particular case, the /* fall through */
>> comments are placed at the bottom of the case statement, which
>> is what GCC is expecting to find.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch is part of the ongoing efforts to enabling
>> -Wimplicit-fallthrough.
>>
>> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
>> ---
>> drivers/net/can/at91_can.c | 6 ++++--
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
>> index d98c69045b17..1718c20f9c99 100644
>> --- a/drivers/net/can/at91_can.c
>> +++ b/drivers/net/can/at91_can.c
>> @@ -902,7 +902,8 @@ static void at91_irq_err_state(struct net_device *dev,
>> CAN_ERR_CRTL_TX_WARNING :
>> CAN_ERR_CRTL_RX_WARNING;
>> }
>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>> + /* fall through */
>
> Why do we need this comment at all? Just remove it, that's all.
>
>> + case CAN_STATE_ERROR_WARNING:
>> /*
>> * from: ERROR_ACTIVE, ERROR_WARNING
>> * to : ERROR_PASSIVE, BUS_OFF
>> @@ -951,7 +952,8 @@ static void at91_irq_err_state(struct net_device *dev,
>> netdev_dbg(dev, "Error Active\n");
>> cf->can_id |= CAN_ERR_PROT;
>> cf->data[2] = CAN_ERR_PROT_ACTIVE;
>> - case CAN_STATE_ERROR_WARNING: /* fallthrough */
>> + /* fall through */
>
> Again, we don;t need it here.
>
>> + case CAN_STATE_ERROR_WARNING:
>> reg_idr = AT91_IRQ_ERRA | AT91_IRQ_WARN | AT91_IRQ_BOFF;
>> reg_ier = AT91_IRQ_ERRP;
>> break;
Ignore me, I misread the code...
MBR, Sergei
^ permalink raw reply
* Re: Possible bug into DSA2 code.
From: Andrew Lunn @ 2019-02-09 19:34 UTC (permalink / raw)
To: Rodolfo Giometti
Cc: Florian Fainelli, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <528f797d-445b-a314-d8ef-db15a3b6a8ce@enneenne.com>
> So we I see two possible solutions:
>
> 1) having both ds->slave_mii_bus and ds->ops->phy_read already defined is an
> error, then it must be signaled to the calling code, or
I don't think we can do that. mv88e6xxx optionally instantiates the
MDIO busses, depending on what is in device tree. If there is no mdio
property, we need the DSA core to create an MDIO bus.
Looking at the driver, ds->slave_mii_bus is assigned in
mv88e6xxx_setup().
We have talked about adding a teardown() to the ops structure. This
seems like another argument we should do it. The mv88e6xxx_teardown()
can set ds->slave_mii_bus back to NULL, undoing what it did in the
setup code.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Add support for asking the PHY its abilities
From: Andrew Lunn @ 2019-02-09 19:42 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <1984f4fa-78df-bb51-5021-306ce87c3a80@gmail.com>
> I know, it's patch 15 in your series ;) And I'm aware that usually new
> core functionality is acceptable only if it comes together with a user,
> to avoid having billions of orphaned good ideas in the code.
> I focused on the core here to not get lost in all the new stuff, and to
> provide Maxime with some direction for adjusting his series.
I'm just trying to avoid Maxime reimplementing something when we
already have a patch:
https://github.com/lunn/linux/commit/07e3fa8f183f05a09d969a9378534da35238eeb9
Maxime, feel free to cherry-pick this into your series.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Add support for asking the PHY its abilities
From: Heiner Kallweit @ 2019-02-09 19:50 UTC (permalink / raw)
To: Andrew Lunn, Maxime Chevallier
Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <20190209194255.GJ30856@lunn.ch>
On 09.02.2019 20:42, Andrew Lunn wrote:
>> I know, it's patch 15 in your series ;) And I'm aware that usually new
>> core functionality is acceptable only if it comes together with a user,
>> to avoid having billions of orphaned good ideas in the code.
>> I focused on the core here to not get lost in all the new stuff, and to
>> provide Maxime with some direction for adjusting his series.
>
> I'm just trying to avoid Maxime reimplementing something when we
> already have a patch:
>
Sure, I didn't mean Maxime should re-implement things we have in the pipe.
I meant it more in a way that he gets an idea in which direction we're moving.
> https://github.com/lunn/linux/commit/07e3fa8f183f05a09d969a9378534da35238eeb9
>
> Maxime, feel free to cherry-pick this into your series.
>
I'll submit this one too.
> Andrew
>
Heiner
Oh, and I just saw: When we talk about/with somebody, we should add him to the
mail addressee list.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: Add support for asking the PHY its abilities
From: Heiner Kallweit @ 2019-02-09 20:08 UTC (permalink / raw)
To: Andrew Lunn, Maxime Chevallier
Cc: Florian Fainelli, David Miller, netdev@vger.kernel.org
In-Reply-To: <addc4332-bf56-dd86-d70f-5001db5192b0@gmail.com>
On 09.02.2019 20:50, Heiner Kallweit wrote:
> On 09.02.2019 20:42, Andrew Lunn wrote:
>>> I know, it's patch 15 in your series ;) And I'm aware that usually new
>>> core functionality is acceptable only if it comes together with a user,
>>> to avoid having billions of orphaned good ideas in the code.
>>> I focused on the core here to not get lost in all the new stuff, and to
>>> provide Maxime with some direction for adjusting his series.
>>
>> I'm just trying to avoid Maxime reimplementing something when we
>> already have a patch:
>>
> Sure, I didn't mean Maxime should re-implement things we have in the pipe.
> I meant it more in a way that he gets an idea in which direction we're moving.
>
>> https://github.com/lunn/linux/commit/07e3fa8f183f05a09d969a9378534da35238eeb9
>>
>> Maxime, feel free to cherry-pick this into your series.
>>
> I'll submit this one too.
>
Just saw that this patch depends on patch 5 of Maxime's series. And it needs a
small change because the generic function was renamed to
genphy_c45_pma_read_abilities(). So indeed it may be better if Maxime adds
this patch to his series.
One comment regarding the pause bits in Maxime's patch 5:
If no pause bit is set the core automatically sets both. So we have to do this
neither in the marvell10g driver nor in the generic read-abilities function.
>> Andrew
>>
Heiner
> Heiner
>
> Oh, and I just saw: When we talk about/with somebody, we should add him to the
> mail addressee list.
>
^ permalink raw reply
* How to set promiscuous mode
From: William Flanagan @ 2019-02-09 20:22 UTC (permalink / raw)
To: netdev
Hi,
Working with iproute2 for a task with Wireshark. I don't see the
command in 'ip' to put an Ethernet port into promiscuous mode. A reply
from the openSuse forum (below) tells me how.
I'm wondering if this should be in the 'MAN ip' page.
Regards,
Bill Flanagan
-------- Forwarded Message --------
Dear konsultor,
tsu2 has just replied to a thread you have subscribed to entitled - LEAP
15 how to set promiscuous mode on eth0? - in the Network/Internet forum
of openSUSE Forums.
This thread is located at:
https://forums.opensuse.org/showthread.php/534881-how-to-set-promiscuous-mode-on-eth0?goto=newpost
Here is the message that has just been posted:
***************
---Quote (Originally by konsultor)---
Thanks, Tsu. Double 'atta boy" for sure.
What I find odd is that neither 'promisc' nor 'promiscuous' appears in
the 'MAN ip" document. Is that a reportable bug?
---End Quote---
MAN authors are typically listed in the document, best to write them
directly.
TSU
***************
There may also be other replies, but you will not receive any more
notifications until you visit the forum again.
All the best,
openSUSE Forums
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unsubscription information:
To unsubscribe from this thread, please visit this page:
https://forums.opensuse.org/subscription.php?do=removesubscription&type=thread&subscriptionid=189629&auth=887f2c6151997a4244524bdac85ff08b
To unsubscribe from ALL threads, please visit this page:
https://forums.opensuse.org/subscription.php?do=viewsubscription&folderid=all
--
Flanagan Consulting
Creative Network Solutions
From Desktop to Data Center
3800 Concorde Parkway, Suite 1500, Chantilly, Virginia 20151 USA
Ph: +1.703.242.8381 Fx: +1.703.242.8391
www.Flanagan-Consulting.com
Flanagan Consulting is a Service Mark of W. A. Flanagan, Inc.
"Beware of false knowledge; it is more dangerous than ignorance."
--George Bernard Shaw
^ permalink raw reply
* [PATCH] net/packet: fix 4gb buffer limit due to overflow check
From: Kal Conley @ 2019-02-09 20:37 UTC (permalink / raw)
To: davem
Cc: kal.conley, Willem de Bruijn, Eric Dumazet, Greg Kroah-Hartman,
Jeff Kirsher, Alexander Duyck, Kirill Tkhai, Vincent Whitchurch,
Li RongQing, Magnus Karlsson, open list:NETWORKING [GENERAL],
open list
When calculating rb->frames_per_block * req->tp_block_nr the result
can overflow. Check it for overflow without limiting the total buffer
size to UINT_MAX.
This change fixes support for packet ring buffers >= UINT_MAX.
---
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index d0945253f43b..d603a430378e 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4291,7 +4291,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
rb->frames_per_block = req->tp_block_size / req->tp_frame_size;
if (unlikely(rb->frames_per_block == 0))
goto out;
- if (unlikely(req->tp_block_size > UINT_MAX / req->tp_block_nr))
+ if (unlikely(rb->frames_per_block > UINT_MAX / req->tp_block_nr))
goto out;
if (unlikely((rb->frames_per_block * req->tp_block_nr) !=
req->tp_frame_nr))
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 15/16] net: switchdev: Replace port attr set SDO with a notification
From: Jiri Pirko @ 2019-02-09 20:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: netdev, David S. Miller, Ido Schimmel, open list,
open list:STAGING SUBSYSTEM, moderated list:ETHERNET BRIDGE, jiri,
andrew, vivien.didelot
In-Reply-To: <83d8f16f-a73d-5aa7-4718-fc45e0fed226@gmail.com>
Sat, Feb 09, 2019 at 01:36:18AM CET, f.fainelli@gmail.com wrote:
>On 2/8/19 4:32 PM, Florian Fainelli wrote:
>> Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
>> from all clients, which were migrated to use switchdev notification in
>> the previous patches.
>>
>> Add a new function switchdev_port_attr_notify() that sends the switchdev
>> notifications SWITCHDEV_PORT_ATTR_SET.
>>
>> Drop __switchdev_port_attr_set() and update switchdev_port_attr_set()
>> likewise.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> include/net/switchdev.h | 18 --------
>> net/switchdev/switchdev.c | 92 ++++++++++-----------------------------
>> 2 files changed, 22 insertions(+), 88 deletions(-)
>>
>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>> index 4c5f7e5430cf..5387ff6f41c5 100644
>> --- a/include/net/switchdev.h
>> +++ b/include/net/switchdev.h
>> @@ -111,21 +111,6 @@ void *switchdev_trans_item_dequeue(struct switchdev_trans *trans);
>>
>> typedef int switchdev_obj_dump_cb_t(struct switchdev_obj *obj);
>>
>> -/**
>> - * struct switchdev_ops - switchdev operations
>> - *
>> - * @switchdev_port_attr_get: Get a port attribute (see switchdev_attr).
>> - *
>> - * @switchdev_port_attr_set: Set a port attribute (see switchdev_attr).
>> - */
>> -struct switchdev_ops {
>> - int (*switchdev_port_attr_get)(struct net_device *dev,
>> - struct switchdev_attr *attr);
>> - int (*switchdev_port_attr_set)(struct net_device *dev,
>> - const struct switchdev_attr *attr,
>> - struct switchdev_trans *trans);
>> -};
>> -
>
>This and the hunk below bisection, I will move that into patch #16 after
>receiving feedback on this.
Looks good. Thanks!
^ permalink raw reply
* [PATCH net-next v2] add snmp counter document
From: yupeng @ 2019-02-09 22:46 UTC (permalink / raw)
To: netdev, davem; +Cc: xiyou.wangcong, rdunlap
add document for tcp retransmission, tcp fast open, syn cookies,
challenge ack, prune and several general counters
Signed-off-by: yupeng <yupeng0921@gmail.com>
---
Documentation/networking/snmp_counter.rst | 184 +++++++++++++++++++++++++++++-
1 file changed, 181 insertions(+), 3 deletions(-)
diff --git a/Documentation/networking/snmp_counter.rst b/Documentation/networking/snmp_counter.rst
index c5642f43..52b026b 100644
--- a/Documentation/networking/snmp_counter.rst
+++ b/Documentation/networking/snmp_counter.rst
@@ -367,16 +367,19 @@ to the accept queue.
TCP Fast Open
=============
* TcpEstabResets
+
Defined in `RFC1213 tcpEstabResets`_.
.. _RFC1213 tcpEstabResets: https://tools.ietf.org/html/rfc1213#page-48
* TcpAttemptFails
+
Defined in `RFC1213 tcpAttemptFails`_.
.. _RFC1213 tcpAttemptFails: https://tools.ietf.org/html/rfc1213#page-48
* TcpOutRsts
+
Defined in `RFC1213 tcpOutRsts`_. The RFC says this counter indicates
the 'segments sent containing the RST flag', but in linux kernel, this
couner indicates the segments kerenl tried to send. The sending
@@ -384,6 +387,30 @@ process might be failed due to some errors (e.g. memory alloc failed).
.. _RFC1213 tcpOutRsts: https://tools.ietf.org/html/rfc1213#page-52
+* TcpExtTCPSpuriousRtxHostQueues
+
+When the TCP stack wants to retransmit a packet, and finds that packet
+is not lost in the network, but the packet is not sent yet, the TCP
+stack would give up the retransmission and update this counter. It
+might happen if a packet stays too long time in a qdisc or driver
+queue.
+
+* TcpEstabResets
+
+The socket receives a RST packet in Establish or CloseWait state.
+
+* TcpExtTCPKeepAlive
+
+This counter indicates many keepalive packets were sent. The keepalive
+won't be enabled by default. A userspace program could enable it by
+setting the SO_KEEPALIVE socket option.
+
+* TcpExtTCPSpuriousRTOs
+
+The spurious retransmission timeout detected by the `F-RTO`_
+algorithm.
+
+.. _F-RTO: https://tools.ietf.org/html/rfc5682
TCP Fast Path
============
@@ -609,6 +636,29 @@ packet yet, the sender would know packet 4 is out of order. The TCP
stack of kernel will increase TcpExtTCPSACKReorder for both of the
above scenarios.
+* TcpExtTCPSlowStartRetrans
+
+The TCP stack wants to retransmit a packet and the congestion control
+state is 'Loss'.
+
+* TcpExtTCPFastRetrans
+
+The TCP stack wants to retransmit a packet and the congestion control
+state is not 'Loss'.
+
+* TcpExtTCPLostRetransmit
+
+A SACK points out that a retransmission packet is lost again.
+
+* TcpExtTCPRetransFail
+
+The TCP stack tries to deliver a retransmission packet to lower layers
+but the lower layers return an error.
+
+* TcpExtTCPSynRetrans
+
+The TCP stack retransmits a SYN packet.
+
DSACK
=====
The DSACK is defined in `RFC2883`_. The receiver uses DSACK to report
@@ -790,8 +840,9 @@ unacknowledged number (more strict than `RFC 5961 section 5.2`_).
.. _RFC 5961 section 5.2: https://tools.ietf.org/html/rfc5961#page-11
TCP receive window
-=================
+==================
* TcpExtTCPWantZeroWindowAdv
+
Depending on current memory usage, the TCP stack tries to set receive
window to zero. But the receive window might still be a no-zero
value. For example, if the previous window size is 10, and the TCP
@@ -799,14 +850,16 @@ stack receives 3 bytes, the current window size would be 7 even if the
window size calculated by the memory usage is zero.
* TcpExtTCPToZeroWindowAdv
+
The TCP receive window is set to zero from a no-zero value.
* TcpExtTCPFromZeroWindowAdv
+
The TCP receive window is set to no-zero value from zero.
Delayed ACK
-==========
+===========
The TCP Delayed ACK is a technique which is used for reducing the
packet count in the network. For more details, please refer the
`Delayed ACK wiki`_
@@ -814,10 +867,12 @@ packet count in the network. For more details, please refer the
.. _Delayed ACK wiki: https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
* TcpExtDelayedACKs
+
A delayed ACK timer expires. The TCP stack will send a pure ACK packet
and exit the delayed ACK mode.
* TcpExtDelayedACKLocked
+
A delayed ACK timer expires, but the TCP stack can't send an ACK
immediately due to the socket is locked by a userspace program. The
TCP stack will send a pure ACK later (after the userspace program
@@ -826,24 +881,147 @@ TCP stack will also update TcpExtDelayedACKs and exit the delayed ACK
mode.
* TcpExtDelayedACKLost
+
It will be updated when the TCP stack receives a packet which has been
ACKed. A Delayed ACK loss might cause this issue, but it would also be
triggered by other reasons, such as a packet is duplicated in the
network.
Tail Loss Probe (TLP)
-===================
+=====================
TLP is an algorithm which is used to detect TCP packet loss. For more
details, please refer the `TLP paper`_.
.. _TLP paper: https://tools.ietf.org/html/draft-dukkipati-tcpm-tcp-loss-probe-01
* TcpExtTCPLossProbes
+
A TLP probe packet is sent.
* TcpExtTCPLossProbeRecovery
+
A packet loss is detected and recovered by TLP.
+TCP Fast Open
+=============
+TCP Fast Open is a technology which allows data transfer before the
+3-way handshake complete. Please refer the `TCP Fast Open wiki`_ for a
+general description.
+
+.. _TCP Fast Open wiki: https://en.wikipedia.org/wiki/TCP_Fast_Open
+
+* TcpExtTCPFastOpenActive
+
+When the TCP stack receives an ACK packet in the SYN-SENT status, and
+the ACK packet acknowledges the data in the SYN packet, the TCP stack
+understand the TFO cookie is accepted by the other side, then it
+updates this counter.
+
+* TcpExtTCPFastOpenActiveFail
+
+This counter indicates that the TCP stack initiated a TCP Fast Open,
+but it failed. This counter would be updated in three scenarios: (1)
+the other side doesn't acknowledge the data in the SYN packet. (2) The
+SYN packet which has the TFO cookie is timeout at least once. (3)
+after the 3-way handshake, the retransmission timeout happens
+net.ipv4.tcp_retries1 times, because some middle-boxes may black-hole
+fast open after the handshake.
+
+* TcpExtTCPFastOpenPassive
+
+This counter indicates how many times the TCP stack accepts the fast
+open request.
+
+* TcpExtTCPFastOpenPassiveFail
+
+This counter indicates how many times the TCP stack rejects the fast
+open request. It is caused by either the TFO cookie is invalid or the
+TCP stack finds an error during the socket creating process.
+
+* TcpExtTCPFastOpenListenOverflow
+
+When the pending fast open request number is larger than
+fastopenq->max_qlen, the TCP stack will reject the fast open request
+and update this counter. When this counter is updated, the TCP stack
+won't update TcpExtTCPFastOpenPassive or
+TcpExtTCPFastOpenPassiveFail. The fastopenq->max_qlen is set by the
+TCP_FASTOPEN socket operation and it could not be larger than
+net.core.somaxconn. For example:
+
+setsockopt(sfd, SOL_TCP, TCP_FASTOPEN, &qlen, sizeof(qlen));
+
+* TcpExtTCPFastOpenCookieReqd
+
+This counter indicates how many times a client wants to request a TFO
+cookie.
+
+SYN cookies
+===========
+SYN cookies are used to mitigate SYN flood, for details, please refer
+the `SYN cookies wiki`_.
+
+.. _SYN cookies wiki: https://en.wikipedia.org/wiki/SYN_cookies
+
+* TcpExtSyncookiesSent
+
+It indicates how many SYN cookies are sent.
+
+* TcpExtSyncookiesRecv
+
+How many reply packets of the SYN cookies the TCP stack receives.
+
+* TcpExtSyncookiesFailed
+
+The MSS decoded from the SYN cookie is invalid. When this counter is
+updated, the received packet won't be treated as a SYN cookie and the
+TcpExtSyncookiesRecv counter wont be updated.
+
+Challenge ACK
+=============
+For details of challenge ACK, please refer the explaination of
+TcpExtTCPACKSkippedChallenge.
+
+* TcpExtTCPChallengeACK
+
+The number of challenge acks sent.
+
+* TcpExtTCPSYNChallenge
+
+The number of challenge acks sent in response to SYN packets. After
+updates this counter, the TCP stack might send a challenge ACK and
+update the TcpExtTCPChallengeACK counter, or it might also skip to
+send the challenge and update the TcpExtTCPACKSkippedChallenge.
+
+prune
+=====
+When a socket is under memory pressure, the TCP stack will try to
+reclaim memory from the receiving queue and out of order queue. One of
+the reclaiming method is 'collapse', which means allocate a big sbk,
+copy the contiguous skbs to the single big skb, and free these
+contiguous skbs.
+
+* TcpExtPruneCalled
+
+The TCP stack tries to reclaim memory for a socket. After updates this
+counter, the TCP stack will try to collapse the out of order queue and
+the receiving queue. If the memory is still not enough, the TCP stack
+will try to discard packets from the out of order queue (and update the
+TcpExtOfoPruned counter)
+
+* TcpExtOfoPruned
+
+The TCP stack tries to discard packet on the out of order queue.
+
+* TcpExtRcvPruned
+
+After 'collapse' and discard packets from the out of order queue, if
+the actually used memory is still larger than the max allowed memory,
+this counter will be updated. It means the 'prune' fails.
+
+* TcpExtTCPRcvCollapsed
+
+This counter indicates how many skbs are freed during 'collapse'.
+
examples
========
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net] sctp: make sctp_setsockopt_events() less strict about the option length
From: David Miller @ 2019-02-09 23:12 UTC (permalink / raw)
To: marcelo.leitner
Cc: julien, netdev, linux-sctp, linux-kernel, nhorman, vyasevich,
lucien.xin
In-Reply-To: <20190206203754.GC13621@localhost.localdomain>
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Wed, 6 Feb 2019 18:37:54 -0200
> On Wed, Feb 06, 2019 at 12:14:30PM -0800, Julien Gomes wrote:
>> Make sctp_setsockopt_events() able to accept sctp_event_subscribe
>> structures longer than the current definitions.
>>
>> This should prevent unjustified setsockopt() failures due to struct
>> sctp_event_subscribe extensions (as in 4.11 and 4.12) when using
>> binaries that should be compatible, but were built with later kernel
>> uapi headers.
>
> Not sure if we support backwards compatibility like this?
What a complete mess we have here.
Use new socket option numbers next time, do not change the size and/or
layout of existing socket options.
This whole thread, if you read it, is basically "if we compatability
this way, that breaks, and if we do compatability this other way oh
shit this other thing doesn't work."
I think we really need to specifically check for the difference sizes
that existed one by one, clear out the part not given by the user, and
backport this as far back as possible in a way that in the older kernels
we see if the user is actually trying to use the new features and if so
error out.
Which, btw, is terrible behavior. Newly compiled apps should work on
older kernels if they don't try to use the new features, and if they
can the ones that want to try to use the new features should be able
to fall back when that feature isn't available in a non-ambiguous
and precisely defined way.
The fact that the use of the new feature is hidden in the new
structure elements is really rotten.
This patch, at best, needs some work and definitely a longer and more
detailed commit message.
^ 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