* Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Russell King - ARM Linux admin @ 2019-02-18 10:43 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20190218102630.GA3784@kwain>
On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> Hi Russell,
>
> On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> > > The documentation advises to set the XPCS in reset while reconfiguring
> > > the serdes lanes. This seems to be a good thing to do, but the PPv2
> > > driver wasn't doing it. This patch fixes it.
> >
> > Hmm. That statment seems to have some ambiguity in it - we do two
> > "reconfigurations" - one may be upon initialisation, where the lane
> > is already configured for 10Gbase-KR, and we're re-initialising it
> > for the same mode. The other case is when we're switching between
> > 10Gbase-KR and SGMII, or as will be the case with 2.5G support for
> > the Alaska PHYs, 2500base-X.
>
> The configuration at the lane at boot time is dependent to the
> firmware or bootloader configuration. On the mcbin, the lane may be
> configured in 10Gbase-KR, but it could be configured in SGMII as well.
> The configuration upon initialization and the re-configuration are quite
> similar then, as we might change mode as well at boot time.
>
> You're right in that we might be re-configuring the lane for the same
> exact mode at boot time, if it was already configured in the same mode.
>
> > Does this apply to reconfiguration of the serdes lane between
> > 10Gbase-KR and slower modes?
>
> This applies only when configuring a line in a 10G mode,
> mvpp22_gop_init_10gkr isn't called otherwise.
>
> When switching to an non-10G mode we might want to put the XPCS in reset
> though, which is not done today with this patch.
I'm merely pointing out the discrepency between the commit message and
what is actually being done. I'm not particularly concerned about what
happens at boot.
We have four different transitions a port can go through, all of which
reconfigure the serdes lanes:
1. 10gkr -> 10gkr
2. 10gkr -> non-10gkr
3. non-10gkr -> non-10gkr
4. non-10gkr -> 10gkr
With this patch, XPCS is only placed into reset during the
reconfiguration for cases 1 and 4. Case 3 doesn't matter (the XPCS
should already be in reset right?) Case 2 isn't covered, and this
leaves a rather big hole.
It seems to me that if the documentation states that the XPCS needs to
be placed in reset while the serdes is reconfigured, then what should
be happening is:
- at boot, place the XPCS into reset.
- when we configure for 10gkr, release the reset once we've finished
configuring the serdes.
- when we configure away from 10gkr, place the XPCS back into reset
before configuring the serdes.
Merely placing the XPCS into reset while we configure the serdes for
10gkr doesn't seem to be "fixing" the driver to conform to your commit
message opening statement.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [RFC] net: dsa: qca8k: implement rgmii-id mode
From: Vinod Koul @ 2019-02-18 10:45 UTC (permalink / raw)
To: Andrew Lunn
Cc: Michal Vokáč, David S. Miller, netdev,
linux-kernel@vger.kernel.org, Florian Fainelli
In-Reply-To: <20190215152356.GP708@lunn.ch>
On 15-02-19, 16:23, Andrew Lunn wrote:
> On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
> > Hi,
> >
> > networking on my boards [1], which are currently in linux-next, suddently
> > stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net: dsa:
> > qca8k: disable delay for RGMII mode") [2].
> >
> > So I think the rgmii-id mode is obviously needed in my case.
> > I was able to find a couple drivers that read tx/rx-delay or
> > tx/rx-internal-delay from device tree. Namely:
> >
> > drivers/net/ethernet/apm/xgene/xgene_enet_main.c
> > drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
> > drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
> > drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
> > drivers/net/phy/dp83867.c
> >
> > I would appreciate any hints how to add similar function to qca8k driver
> > if that is the correct way to go. Can I take some of the above mentioned
> > drivers as a good example for that? How should the binding look like?
> >
> > I would expect something like this:
> >
> > switch@0 {
> > compatible = "qca,qca8334";
> > reg = <0>;
> >
> > switch_ports: ports {
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > ethphy0: port@0 {
> > reg = <0>;
> > label = "cpu";
> > phy-mode = "rgmii-id";
> > qca,tx-delay = <3>;
> > qca,rx-delay = <3>;
> > ethernet = <&fec>;
> > };
>
> Hi Michal
>
> Your submission used:
>
> + ethphy0: port@0 {
> + reg = <0>;
> + label = "cpu";
> + phy-mode = "rgmii";
> + ethernet = <&fec>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
>
> This is good. If you have a fixed-link you can pass a phy-mode.
>
> The comment that was removed was:
>
> - /* According to the datasheet, RGMII delay is enabled through
> - * PORT5_PAD_CTRL for all ports, rather than individual port
> - * registers
> - */
>
> Is it possible to enable delays per port? Ideally, you want to enable
> delays for just selected ports. Add another case for
> PHY_INTERFACE_MODE_RGMII_ID to enable the delays.
In the hindsight I should not have removed the comment, let me ressurect
that as well as add handling of the RGMII modes...
Please do test
Thanks
--
~Vinod
^ permalink raw reply
* Re: Possible bug into DSA2 code.
From: Rodolfo Giometti @ 2019-02-18 10:38 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn; +Cc: Vivien Didelot, David S. Miller, netdev
In-Reply-To: <24527f56-41dd-f257-0f5e-c568cb80881e@gmail.com>
On 11/02/2019 20:13, Florian Fainelli wrote:
> Does that work:
>
> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> index a1917025e155..54cf6a5c865d 100644
> --- a/net/dsa/dsa2.c
> +++ b/net/dsa/dsa2.c
> @@ -368,6 +368,9 @@ static int dsa_switch_setup(struct dsa_switch *ds)
> if (err)
> return err;
>
> + if (ds->slave_mii_bus && (ds->ops->phy_read || ds->ops->phy_write))
> + return -EINVAL;
> +
> if (!ds->slave_mii_bus && ds->ops->phy_read) {
> ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
> if (!ds->slave_mii_bus)
> diff --git a/net/dsa/legacy.c b/net/dsa/legacy.c
> index cb42939db776..0796c6213be6 100644
> --- a/net/dsa/legacy.c
> +++ b/net/dsa/legacy.c
> @@ -176,6 +176,9 @@ static int dsa_switch_setup_one(struct dsa_switch *ds,
> if (ret)
> return ret;
>
> + if (ds->slave_mii_bus && (ops->phy_read || ops->phy_write))
> + return -EINVAL;
> +
> if (!ds->slave_mii_bus && ops->phy_read) {
> ds->slave_mii_bus = devm_mdiobus_alloc(ds->dev);
> if (!ds->slave_mii_bus)
OK, now probing of mv88e6085 fails!
[ 42.745004] mv88e6085: probe of d0032004.mdio-mii:01 failed with error -22
Now I suppose mv88e6085's driver should set ds->slave_mii_bus as follow:
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 54a5b660640a..bb46ebbb2bb8 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2399,7 +2399,7 @@ static int mv88e6xxx_setup(struct dsa_switch *ds)
int i;
chip->ds = ds;
- ds->slave_mii_bus = mv88e6xxx_default_mdio_bus(chip);
+ ds->slave_mii_bus = NULL;
mutex_lock(&chip->reg_lock);
Is that right?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@linux.it
Embedded Systems phone: +39 349 2432127
UNIX programming skype: rodolfo.giometti
^ permalink raw reply related
* Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Russell King - ARM Linux admin @ 2019-02-18 10:47 UTC (permalink / raw)
To: Antoine Tenart
Cc: davem, netdev, linux-kernel, thomas.petazzoni, maxime.chevallier,
gregory.clement, miquel.raynal, nadavh, stefanc, ymarkman, mw
In-Reply-To: <20190218104302.bp6ccmpkt26dflyx@shell.armlinux.org.uk>
On Mon, Feb 18, 2019 at 10:43:02AM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> > Hi Russell,
> >
> > On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > > On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> > > > The documentation advises to set the XPCS in reset while reconfiguring
> > > > the serdes lanes. This seems to be a good thing to do, but the PPv2
> > > > driver wasn't doing it. This patch fixes it.
> > >
> > > Hmm. That statment seems to have some ambiguity in it - we do two
> > > "reconfigurations" - one may be upon initialisation, where the lane
> > > is already configured for 10Gbase-KR, and we're re-initialising it
> > > for the same mode. The other case is when we're switching between
> > > 10Gbase-KR and SGMII, or as will be the case with 2.5G support for
> > > the Alaska PHYs, 2500base-X.
> >
> > The configuration at the lane at boot time is dependent to the
> > firmware or bootloader configuration. On the mcbin, the lane may be
> > configured in 10Gbase-KR, but it could be configured in SGMII as well.
> > The configuration upon initialization and the re-configuration are quite
> > similar then, as we might change mode as well at boot time.
> >
> > You're right in that we might be re-configuring the lane for the same
> > exact mode at boot time, if it was already configured in the same mode.
> >
> > > Does this apply to reconfiguration of the serdes lane between
> > > 10Gbase-KR and slower modes?
> >
> > This applies only when configuring a line in a 10G mode,
> > mvpp22_gop_init_10gkr isn't called otherwise.
> >
> > When switching to an non-10G mode we might want to put the XPCS in reset
> > though, which is not done today with this patch.
>
> I'm merely pointing out the discrepency between the commit message and
> what is actually being done. I'm not particularly concerned about what
> happens at boot.
>
> We have four different transitions a port can go through, all of which
> reconfigure the serdes lanes:
>
> 1. 10gkr -> 10gkr
> 2. 10gkr -> non-10gkr
> 3. non-10gkr -> non-10gkr
> 4. non-10gkr -> 10gkr
>
> With this patch, XPCS is only placed into reset during the
> reconfiguration for cases 1 and 4. Case 3 doesn't matter (the XPCS
> should already be in reset right?) Case 2 isn't covered, and this
> leaves a rather big hole.
>
> It seems to me that if the documentation states that the XPCS needs to
> be placed in reset while the serdes is reconfigured, then what should
> be happening is:
>
> - at boot, place the XPCS into reset.
> - when we configure for 10gkr, release the reset once we've finished
> configuring the serdes.
> - when we configure away from 10gkr, place the XPCS back into reset
> before configuring the serdes.
>
> Merely placing the XPCS into reset while we configure the serdes for
> 10gkr doesn't seem to be "fixing" the driver to conform to your commit
> message opening statement.
Another case that needs to be considered: if the XPCS should be placed
into reset while reconfiguring the serdes lanes, is the same treatment
needed for the GMAC?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH RESEND 0/3] Add quirk for reading BD_ADDR from fwnode property
From: Marcel Holtmann @ 2019-02-18 10:48 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Johan Hedberg, David S. Miller, Loic Poulain, linux-bluetooth,
linux-kernel, netdev, Balakrishna Godavarthi
In-Reply-To: <20190131221021.176809-1-mka@chromium.org>
Hi Matthias,
> [initial post: https://lore.kernel.org/patchwork/cover/1028184/]
>
> On some systems the Bluetooth Device Address (BD_ADDR) isn't stored
> on the Bluetooth chip itself. One way to configure the address is
> through the device tree (patched in by the bootloader). The btqcomsmd
> driver is an example, it can read the address from the DT property
> 'local-bd-address'.
>
> To avoid redundant open-coded reading of 'local-bd-address' and error
> handling this series adds the quirk HCI_QUIRK_USE_BDADDR_PROPERTY to
> retrieve the BD address of a device from the DT and adapts the
> btqcomsmd and hci_qca drivers to use this quirk.
>
> Matthias Kaehlcke (3):
> Bluetooth: Add quirk for reading BD_ADDR from fwnode property
> Bluetooth: btqcomsmd: use HCI_QUIRK_USE_BDADDR_PROPERTY
> Bluetooth: hci_qca: Set HCI_QUIRK_USE_BDADDR_PROPERTY for wcn3990
>
> drivers/bluetooth/btqcomsmd.c | 29 +++--------------------
> drivers/bluetooth/hci_qca.c | 1 +
> include/net/bluetooth/hci.h | 12 ++++++++++
> net/bluetooth/hci_core.c | 43 +++++++++++++++++++++++++++++++++++
> net/bluetooth/mgmt.c | 6 +++--
> 5 files changed, 63 insertions(+), 28 deletions(-)
I am getting compiler warnings when trying to apply this set:
CC drivers/bluetooth/btqcomsmd.o
drivers/bluetooth/btqcomsmd.c: In function ‘btqcomsmd_setup’:
drivers/bluetooth/btqcomsmd.c:120:6: warning: unused variable ‘err’ [-Wunused-variable]
int err;
^~~
drivers/bluetooth/btqcomsmd.c:118:20: warning: unused variable ‘btq’ [-Wunused-variable]
struct btqcomsmd *btq = hci_get_drvdata(hdev);
^~~
Regards
Marcel
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the rdma tree
From: Leon Romanovsky @ 2019-02-18 10:48 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, Doug Ledford, Jason Gunthorpe,
Linux Next Mailing List, Linux Kernel Mailing List, Mark Bloch,
Bodong Wang, Saeed Mahameed
In-Reply-To: <20190218110549.7f22feda@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
On Mon, Feb 18, 2019 at 11:05:49AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/infiniband/hw/mlx5/ib_rep.c
>
> between commits:
>
> 459cc69fa4c1 ("RDMA: Provide safe ib_alloc_device() function")
> fc9e4477f924 ("RDMA/mlx5: Fix memory leak in case we fail to add an IB device")
>
> from the rdma tree and commit:
>
> f0666f1f22b5 ("IB/mlx5: Use unified register/load function for uplink and VF vports")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
Thanks a lot for your resolution.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Antoine Tenart @ 2019-02-18 10:50 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Antoine Tenart, davem, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20190218104302.bp6ccmpkt26dflyx@shell.armlinux.org.uk>
Russell,
On Mon, Feb 18, 2019 at 10:43:02AM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Feb 18, 2019 at 11:26:30AM +0100, Antoine Tenart wrote:
> > On Fri, Feb 15, 2019 at 05:12:24PM +0000, Russell King - ARM Linux admin wrote:
> > > On Fri, Feb 15, 2019 at 04:32:38PM +0100, Antoine Tenart wrote:
> > > > The documentation advises to set the XPCS in reset while reconfiguring
> > > > the serdes lanes. This seems to be a good thing to do, but the PPv2
> > > > driver wasn't doing it. This patch fixes it.
> > >
> > > Hmm. That statment seems to have some ambiguity in it - we do two
> > > "reconfigurations" - one may be upon initialisation, where the lane
> > > is already configured for 10Gbase-KR, and we're re-initialising it
> > > for the same mode. The other case is when we're switching between
> > > 10Gbase-KR and SGMII, or as will be the case with 2.5G support for
> > > the Alaska PHYs, 2500base-X.
> >
> > The configuration at the lane at boot time is dependent to the
> > firmware or bootloader configuration. On the mcbin, the lane may be
> > configured in 10Gbase-KR, but it could be configured in SGMII as well.
> > The configuration upon initialization and the re-configuration are quite
> > similar then, as we might change mode as well at boot time.
> >
> > You're right in that we might be re-configuring the lane for the same
> > exact mode at boot time, if it was already configured in the same mode.
> >
> > > Does this apply to reconfiguration of the serdes lane between
> > > 10Gbase-KR and slower modes?
> >
> > This applies only when configuring a line in a 10G mode,
> > mvpp22_gop_init_10gkr isn't called otherwise.
> >
> > When switching to an non-10G mode we might want to put the XPCS in reset
> > though, which is not done today with this patch.
>
> I'm merely pointing out the discrepency between the commit message and
> what is actually being done. I'm not particularly concerned about what
> happens at boot.
>
> We have four different transitions a port can go through, all of which
> reconfigure the serdes lanes:
>
> 1. 10gkr -> 10gkr
> 2. 10gkr -> non-10gkr
> 3. non-10gkr -> non-10gkr
> 4. non-10gkr -> 10gkr
>
> With this patch, XPCS is only placed into reset during the
> reconfiguration for cases 1 and 4. Case 3 doesn't matter (the XPCS
> should already be in reset right?) Case 2 isn't covered, and this
> leaves a rather big hole.
>
> It seems to me that if the documentation states that the XPCS needs to
> be placed in reset while the serdes is reconfigured, then what should
> be happening is:
>
> - at boot, place the XPCS into reset.
> - when we configure for 10gkr, release the reset once we've finished
> configuring the serdes.
> - when we configure away from 10gkr, place the XPCS back into reset
> before configuring the serdes.
>
> Merely placing the XPCS into reset while we configure the serdes for
> 10gkr doesn't seem to be "fixing" the driver to conform to your commit
> message opening statement.
That's right, we should put the XPCS in reset when booting and when
switching away from a 10G mode. I'll fix that in v2.
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Antoine Tenart @ 2019-02-18 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Antoine Tenart, davem, netdev, linux-kernel, thomas.petazzoni,
maxime.chevallier, gregory.clement, miquel.raynal, nadavh,
stefanc, ymarkman, mw
In-Reply-To: <20190218104757.be63b5ft5jpongn3@shell.armlinux.org.uk>
Russell,
On Mon, Feb 18, 2019 at 10:47:57AM +0000, Russell King - ARM Linux admin wrote:
>
> Another case that needs to be considered: if the XPCS should be placed
> into reset while reconfiguring the serdes lanes, is the same treatment
> needed for the GMAC?
That's something I wanted to check as well. I don't know for the GMAC,
while I'm sure the documentation explicitly state to put the XPCS in
reset when reconfiguring the lanes.
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH net-next v4 07/17] net: sched: protect filter_chain list with filter_chain_lock mutex
From: Vlad Buslov @ 2019-02-18 11:06 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAM_iQpVJ69Uib2Y4GqVZ4eHd25JrUZCa=d4ZGq4WCd+Q4vVi1g@mail.gmail.com>
On Fri 15 Feb 2019 at 22:35, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> +#ifdef CONFIG_PROVE_LOCKING
>> +static inline bool lockdep_tcf_chain_is_locked(struct tcf_chain *chain)
>> +{
>> + return lockdep_is_held(&chain->filter_chain_lock);
>> +}
>> +#else
>> +static inline bool lockdep_tcf_chain_is_locked(struct tcf_block *chain)
>> +{
>> + return true;
>> +}
>> +#endif /* #ifdef CONFIG_PROVE_LOCKING */
>> +
>> +#define tcf_chain_dereference(p, chain) \
>> + rcu_dereference_protected(p, lockdep_tcf_chain_is_locked(chain))
>
>
> Are you sure you need this #ifdef CONFIG_PROVE_LOCKING?
> rcu_dereference_protected() should already test CONFIG_PROVE_RCU.
>
> Ditto for tcf_proto_dereference().
I implemented these macro same way as rtnl_dereference() is implemented,
which they are intended to substitute.
After removing them I get following compilation error with
CONFIG_PROVE_LOCKING disabled:
./include/net/sch_generic.h: In function ‘lockdep_tcf_chain_is_locked’:
./include/net/sch_generic.h:404:9: error: implicit declaration of function ‘lockdep_is_held’; did you mean ‘lockdep_rtnl_is_held’? [-Werror=implicit-function-declaration]
return lockdep_is_held(&chain->filter_chain_lock);
^~~~~~~~~~~~~~~
lockdep_rtnl_is_held
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Stefan Chulski @ 2019-02-18 11:08 UTC (permalink / raw)
To: Antoine Tenart, Russell King - ARM Linux admin
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, gregory.clement@bootlin.com,
miquel.raynal@bootlin.com, Nadav Haklai, Yan Markman,
mw@semihalf.com
In-Reply-To: <20190218105222.GD3784@kwain>
> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Monday, February 18, 2019 12:52 PM
> To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Stefan Chulski <stefanc@marvell.com>; Yan
> Markman <ymarkman@marvell.com>; mw@semihalf.com
> Subject: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while
> reconfiguring the serdes lanes
>
> External Email
>
> ----------------------------------------------------------------------
> Russell,
>
> On Mon, Feb 18, 2019 at 10:47:57AM +0000, Russell King - ARM Linux admin
> wrote:
> >
> > Another case that needs to be considered: if the XPCS should be placed
> > into reset while reconfiguring the serdes lanes, is the same treatment
> > needed for the GMAC?
>
> That's something I wanted to check as well. I don't know for the GMAC, while
> I'm sure the documentation explicitly state to put the XPCS in reset when
> reconfiguring the lanes.
HW recommendation upon Serdes reconfiguration are the following:
1. Disable port(CTRL0_REG - in XLG/GMAC)
2. Put port in reset (both XLG/GMAC)
3. For KR - put in reset MPCS (MAC control clock, RX SD clock, TX SD clock), XPSC is RXAUI/XAUI clock domain
4. Power down Serdes lane
Do reconfiguration of Serdes.
5. Enable Serdes lane
6. Disable MPCS reset for KR
7. Disable port reset (both XLG/GMAC)
8. Enable port (both XLG/GMAC)
Stefan,
Best Regards.
^ permalink raw reply
* Re: [PATCH net-next v4 10/17] net: sched: refactor tp insert/delete for concurrent execution
From: Vlad Buslov @ 2019-02-18 11:19 UTC (permalink / raw)
To: Cong Wang
Cc: Linux Kernel Network Developers, Jamal Hadi Salim, Jiri Pirko,
David Miller, Alexei Starovoitov, Daniel Borkmann
In-Reply-To: <CAM_iQpVdO5G9a+C4FecORHOuO7uKu6=fqKa-CUTyFMd_heyU+Q@mail.gmail.com>
On Fri 15 Feb 2019 at 23:17, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Mon, Feb 11, 2019 at 12:56 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>> +static bool tcf_proto_is_empty(struct tcf_proto *tp)
>> +{
>> + struct tcf_walker walker = { .fn = walker_noop, };
>> +
>> + if (tp->ops->walk) {
>> + tp->ops->walk(tp, &walker);
>> + return !walker.stop;
>> + }
>> + return true;
>> +}
>> +
>> +static bool tcf_proto_check_delete(struct tcf_proto *tp)
>> +{
>> + spin_lock(&tp->lock);
>> + if (tcf_proto_is_empty(tp))
>> + tp->deleting = true;
>> + spin_unlock(&tp->lock);
>> + return tp->deleting;
>
> If you use this spinlock for walking each tp data structure,
> why it is not needed for adding to/deleting filters from each
> tp?
This lock is intended to be used by unlocked classifiers and I use it in
my following flower patch set extensively. Classifiers that do not set
'unlocked' flag continue to rely on rtnl lock for synchronization.
^ permalink raw reply
* Re: [PATCH bpf-next v4 1/2] libbpf: add support for using AF_XDP sockets
From: Maciej Fijalkowski @ 2019-02-18 11:21 UTC (permalink / raw)
To: Magnus Karlsson
Cc: Daniel Borkmann, Magnus Karlsson, Björn Töpel, ast,
Network Development, Jakub Kicinski, Björn Töpel,
Zhang, Qi Z, Jesper Dangaard Brouer, xiaolong.ye
In-Reply-To: <CAJ8uoz1xjv8OBAn==S3EBiGvTqp_dd_t7YQqp2TOSR6JSOdrnA@mail.gmail.com>
On Mon, 18 Feb 2019 09:59:30 +0100
Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> On Fri, Feb 15, 2019 at 6:09 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > On 02/08/2019 02:05 PM, Magnus Karlsson wrote:
> > > This commit adds AF_XDP support to libbpf. The main reason for this is
> > > to facilitate writing applications that use AF_XDP by offering
> > > higher-level APIs that hide many of the details of the AF_XDP
> > > uapi. This is in the same vein as libbpf facilitates XDP adoption by
> > > offering easy-to-use higher level interfaces of XDP
> > > functionality. Hopefully this will facilitate adoption of AF_XDP, make
> > > applications using it simpler and smaller, and finally also make it
> > > possible for applications to benefit from optimizations in the AF_XDP
> > > user space access code. Previously, people just copied and pasted the
> > > code from the sample application into their application, which is not
> > > desirable.
> > >
> > > The interface is composed of two parts:
> > >
> > > * Low-level access interface to the four rings and the packet
> > > * High-level control plane interface for creating and setting
> > > up umems and af_xdp sockets as well as a simple XDP program.
> > >
> > > Tested-by: Björn Töpel <bjorn.topel@intel.com>
> > > Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
> > [...]
> > > diff --git a/tools/lib/bpf/xsk.c b/tools/lib/bpf/xsk.c
> > > new file mode 100644
> > > index 0000000..a982a76
> > > --- /dev/null
> > > +++ b/tools/lib/bpf/xsk.c
> > > @@ -0,0 +1,742 @@
> > > +// SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause)
> > > +
> > > +/*
> > > + * AF_XDP user-space access library.
> > > + *
> > > + * Copyright(c) 2018 - 2019 Intel Corporation.
> > > + *
> > > + * Author(s): Magnus Karlsson <magnus.karlsson@intel.com>
> > > + */
> > > +
> > > +#include <errno.h>
> > > +#include <stdlib.h>
> > > +#include <string.h>
> > > +#include <unistd.h>
> > > +#include <arpa/inet.h>
> > > +#include <asm/barrier.h>
> > > +#include <linux/compiler.h>
> > > +#include <linux/filter.h>
> > > +#include <linux/if_ether.h>
> > > +#include <linux/if_link.h>
> > > +#include <linux/if_packet.h>
> > > +#include <linux/if_xdp.h>
> > > +#include <linux/rtnetlink.h>
> > > +#include <net/if.h>
> > > +#include <sys/mman.h>
> > > +#include <sys/socket.h>
> > > +#include <sys/types.h>
> > > +
> > > +#include "bpf.h"
> > > +#include "libbpf.h"
> > > +#include "libbpf_util.h"
> > > +#include "nlattr.h"
> > > +#include "xsk.h"
> > > +
> > > +#ifndef SOL_XDP
> > > + #define SOL_XDP 283
> > > +#endif
> > > +
> > > +#ifndef AF_XDP
> > > + #define AF_XDP 44
> > > +#endif
> > > +
> > > +#ifndef PF_XDP
> > > + #define PF_XDP AF_XDP
> > > +#endif
> > > +
> > > +struct xsk_umem {
> > > + struct xsk_ring_prod *fill;
> > > + struct xsk_ring_cons *comp;
> > > + char *umem_area;
> > > + struct xsk_umem_config config;
> > > + int fd;
> > > + int refcount;
> > > +};
> > > +
> > > +struct xsk_socket {
> > > + struct xsk_ring_cons *rx;
> > > + struct xsk_ring_prod *tx;
> > > + __u64 outstanding_tx;
> > > + struct xsk_umem *umem;
> > > + struct xsk_socket_config config;
> > > + int fd;
> > > + int xsks_map;
> > > + int ifindex;
> > > + int prog_fd;
> > > + int qidconf_map_fd;
> > > + int xsks_map_fd;
> > > + __u32 queue_id;
> > > +};
> > > +
> > > +struct xsk_nl_info {
> > > + bool xdp_prog_attached;
> > > + int ifindex;
> > > + int fd;
> > > +};
> > > +
> > > +#define MAX_QUEUES 128
> >
> > Why is this a fixed constant here, shouldn't this be dynamic due to being NIC
> > specific anyway?
>
> It was only here for simplicity. If a NIC had more queues, it would
> require a recompile of the lib. Obviously, not desirable in a distro.
> What I could do is to read the max "combined" queues (pre-set maximum
> in the ethtool output) from the same interface as ethool uses and size
> the array after that. Or is there a simpler way? What to do if the NIC
> does not have a "combined", or is there no such NIC (seems the common
> HW ones set this)?
>
> > [...]
> > > +void *xsk_umem__get_data(struct xsk_umem *umem, __u64 addr)
> > > +{
> > > + return &((char *)(umem->umem_area))[addr];
> > > +}
> >
> > There's also a xsk_umem__get_data_raw() doing the same. Why having both, resp.
> > when to choose which? ;)
>
> There is enough to have the xsk_umem__get_data_raw() function.
> xsk_umem__get_data() is just a convenience function for which the
> application does not have to store the beginning of the umem. But as
> the application always has to provide this anyway in the
> xsk_umem__create() function, it might as well store this pointer. I
> will delete xsk_umem__get_data() and rename xsk_umem__get_data_raw()
> to xsk_umem__get_data().
>
> > > +int xsk_umem__fd(const struct xsk_umem *umem)
> > > +{
> > > + return umem ? umem->fd : -EINVAL;
> > > +}
> > > +
> > > +int xsk_socket__fd(const struct xsk_socket *xsk)
> > > +{
> > > + return xsk ? xsk->fd : -EINVAL;
> > > +}
> > > +
> > > +static bool xsk_page_aligned(void *buffer)
> > > +{
> > > + unsigned long addr = (unsigned long)buffer;
> > > +
> > > + return !(addr & (getpagesize() - 1));
> > > +}
> > > +
> > > +static void xsk_set_umem_config(struct xsk_umem_config *cfg,
> > > + const struct xsk_umem_config *usr_cfg)
> > > +{
> > > + if (!usr_cfg) {
> > > + cfg->fill_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
> > > + cfg->comp_size = XSK_RING_CONS__DEFAULT_NUM_DESCS;
> > > + cfg->frame_size = XSK_UMEM__DEFAULT_FRAME_SIZE;
> > > + cfg->frame_headroom = XSK_UMEM__DEFAULT_FRAME_HEADROOM;
> > > + return;
> > > + }
> > > +
> > > + cfg->fill_size = usr_cfg->fill_size;
> > > + cfg->comp_size = usr_cfg->comp_size;
> > > + cfg->frame_size = usr_cfg->frame_size;
> > > + cfg->frame_headroom = usr_cfg->frame_headroom;
> >
> > Just optional nit, might be a bit nicer to have it in this form:
> >
> > cfg->fill_size = usr_cfg ? usr_cfg->fill_size :
> > XSK_RING_PROD__DEFAULT_NUM_DESCS;
>
> I actually think the current form is clearer when there are multiple
> lines. If there was only one line, I would agree with you.
>
> > > +}
> > > +
> > > +static void xsk_set_xdp_socket_config(struct xsk_socket_config *cfg,
> > > + const struct xsk_socket_config *usr_cfg)
> > > +{
> > > + if (!usr_cfg) {
> > > + cfg->rx_size = XSK_RING_CONS__DEFAULT_NUM_DESCS;
> > > + cfg->tx_size = XSK_RING_PROD__DEFAULT_NUM_DESCS;
> > > + cfg->libbpf_flags = 0;
> > > + cfg->xdp_flags = 0;
> > > + cfg->bind_flags = 0;
> > > + return;
> > > + }
> > > +
> > > + cfg->rx_size = usr_cfg->rx_size;
> > > + cfg->tx_size = usr_cfg->tx_size;
> > > + cfg->libbpf_flags = usr_cfg->libbpf_flags;
> > > + cfg->xdp_flags = usr_cfg->xdp_flags;
> > > + cfg->bind_flags = usr_cfg->bind_flags;
> >
> > (Ditto)
> >
> > > +}
> > > +
> > > +int xsk_umem__create(struct xsk_umem **umem_ptr, void *umem_area, __u64 size,
> > > + struct xsk_ring_prod *fill, struct xsk_ring_cons *comp,
> > > + const struct xsk_umem_config *usr_config)
> > > +{
> > > + struct xdp_mmap_offsets off;
> > > + struct xdp_umem_reg mr;
> > > + struct xsk_umem *umem;
> > > + socklen_t optlen;
> > > + void *map;
> > > + int err;
> > > +
> > > + if (!umem_area || !umem_ptr || !fill || !comp)
> > > + return -EFAULT;
> > > + if (!size && !xsk_page_aligned(umem_area))
> > > + return -EINVAL;
> > > +
> > > + umem = calloc(1, sizeof(*umem));
> > > + if (!umem)
> > > + return -ENOMEM;
> > > +
> > > + umem->fd = socket(AF_XDP, SOCK_RAW, 0);
> > > + if (umem->fd < 0) {
> > > + err = -errno;
> > > + goto out_umem_alloc;
> > > + }
> > > +
> > > + umem->umem_area = umem_area;
> > > + xsk_set_umem_config(&umem->config, usr_config);
> > > +
> > > + mr.addr = (uintptr_t)umem_area;
> > > + mr.len = size;
> > > + mr.chunk_size = umem->config.frame_size;
> > > + mr.headroom = umem->config.frame_headroom;
> > > +
> > > + err = setsockopt(umem->fd, SOL_XDP, XDP_UMEM_REG, &mr, sizeof(mr));
> > > + if (err) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > + err = setsockopt(umem->fd, SOL_XDP, XDP_UMEM_FILL_RING,
> > > + &umem->config.fill_size,
> > > + sizeof(umem->config.fill_size));
> > > + if (err) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > + err = setsockopt(umem->fd, SOL_XDP, XDP_UMEM_COMPLETION_RING,
> > > + &umem->config.comp_size,
> > > + sizeof(umem->config.comp_size));
> > > + if (err) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > +
> > > + optlen = sizeof(off);
> > > + err = getsockopt(umem->fd, SOL_XDP, XDP_MMAP_OFFSETS, &off, &optlen);
> > > + if (err) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > +
> > > + map = xsk_mmap(NULL, off.fr.desc +
> > > + umem->config.fill_size * sizeof(__u64),
> > > + PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
> > > + umem->fd, XDP_UMEM_PGOFF_FILL_RING);
> > > + if (map == MAP_FAILED) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > +
> > > + umem->fill = fill;
> > > + fill->mask = umem->config.fill_size - 1;
> > > + fill->size = umem->config.fill_size;
> > > + fill->producer = map + off.fr.producer;
> > > + fill->consumer = map + off.fr.consumer;
> > > + fill->ring = map + off.fr.desc;
> > > + fill->cached_cons = umem->config.fill_size;
> > > +
> > > + map = xsk_mmap(NULL,
> > > + off.cr.desc + umem->config.comp_size * sizeof(__u64),
> > > + PROT_READ | PROT_WRITE, MAP_SHARED | MAP_POPULATE,
> > > + umem->fd, XDP_UMEM_PGOFF_COMPLETION_RING);
> > > + if (map == MAP_FAILED) {
> > > + err = -errno;
> > > + goto out_mmap;
> > > + }
> > > +
> > > + umem->comp = comp;
> > > + comp->mask = umem->config.comp_size - 1;
> > > + comp->size = umem->config.comp_size;
> > > + comp->producer = map + off.cr.producer;
> > > + comp->consumer = map + off.cr.consumer;
> > > + comp->ring = map + off.cr.desc;
> > > +
> > > + *umem_ptr = umem;
> > > + return 0;
> > > +
> > > +out_mmap:
> > > + munmap(umem->fill,
> > > + off.fr.desc + umem->config.fill_size * sizeof(__u64));
> > > +out_socket:
> > > + close(umem->fd);
> > > +out_umem_alloc:
> > > + free(umem);
> > > + return err;
> > > +}
> > > +
> > > +static int xsk_parse_nl(void *cookie, void *msg, struct nlattr **tb)
> > > +{
> > > + struct nlattr *tb_parsed[IFLA_XDP_MAX + 1];
> > > + struct xsk_nl_info *nl_info = cookie;
> > > + struct ifinfomsg *ifinfo = msg;
> > > + unsigned char mode;
> > > + int err;
> > > +
> > > + if (nl_info->ifindex && nl_info->ifindex != ifinfo->ifi_index)
> > > + return 0;
> > > +
> > > + if (!tb[IFLA_XDP])
> > > + return 0;
> > > +
> > > + err = libbpf_nla_parse_nested(tb_parsed, IFLA_XDP_MAX, tb[IFLA_XDP],
> > > + NULL);
> > > + if (err)
> > > + return err;
> > > +
> > > + if (!tb_parsed[IFLA_XDP_ATTACHED] || !tb_parsed[IFLA_XDP_FD])
> > > + return 0;
> > > +
> > > + mode = libbpf_nla_getattr_u8(tb_parsed[IFLA_XDP_ATTACHED]);
> > > + if (mode == XDP_ATTACHED_NONE)
> > > + return 0;
> > > +
> > > + nl_info->xdp_prog_attached = true;
> > > + nl_info->fd = libbpf_nla_getattr_u32(tb_parsed[IFLA_XDP_FD]);
> >
> > Hm, I don't think this works if I read the intention of this helper correctly.
> >
> > IFLA_XDP_FD is never set for retrieving the prog from the kernel. So the
> > above is a bug.
> >
> > We also have bpf_get_link_xdp_id(). This should probably just be reused in
> > this context here.
>
> If bpf_get_link_xdp_id() will fit my bill, I will happily use it. I
> will check it out and hopefully I can drop all this code. Thanks.
>
I see that all you need to know is whether there's already attached XDP program
to xsk socket's related interface, no?
If so, then within the xsk_setup_xdp_prog, you could do something like:
u32 prog_id = 0;
bpf_get_link_xdp_id(xsk->ifindex, &prog_id, xsk->config.xdp_flags);
if (!prog_id) {
// create maps
// load xdp prog
} else {
xsk->fd = prog_id;
}
xsk_update_bpf_maps(xsk, true, xsk->fd);
If that's ok then xsk_xdp_prog_attached and xsk_parse_nl could be dropped.
> > > + return 0;
> > > +}
> > > +
> > > +static bool xsk_xdp_prog_attached(struct xsk_socket *xsk)
> > > +{
> > > + struct xsk_nl_info nl_info;
> > > + unsigned int nl_pid;
> > > + char err_buf[256];
> > > + int sock, err;
> > > +
> > > + sock = libbpf_netlink_open(&nl_pid);
> > > + if (sock < 0)
> > > + return false;
> > > +
> > > + nl_info.xdp_prog_attached = false;
> > > + nl_info.ifindex = xsk->ifindex;
> > > + nl_info.fd = -1;
> > > +
> > > + err = libbpf_nl_get_link(sock, nl_pid, xsk_parse_nl, &nl_info);
> > > + if (err) {
> > > + libbpf_strerror(err, err_buf, sizeof(err_buf));
> > > + pr_warning("Error:\n%s\n", err_buf);
> > > + close(sock);
> > > + return false;
> > > + }
> > > +
> > > + close(sock);
> > > + xsk->prog_fd = nl_info.fd;
> > > + return nl_info.xdp_prog_attached;
> > > +}
> >
> > (See bpf_get_link_xdp_id().)
> >
> > > +
> > > +static int xsk_load_xdp_prog(struct xsk_socket *xsk)
> > > +{
> > > + char bpf_log_buf[BPF_LOG_BUF_SIZE];
> > > + int err, prog_fd;
> > > +
> > > + /* This is the C-program:
> > > + * SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx)
> > > + * {
> > > + * int *qidconf, index = ctx->rx_queue_index;
> > [...]
> > > +
> > > +int xsk_socket__create(struct xsk_socket **xsk_ptr, const char *ifname,
> > > + __u32 queue_id, struct xsk_umem *umem,
> > > + struct xsk_ring_cons *rx, struct xsk_ring_prod *tx,
> > > + const struct xsk_socket_config *usr_config)
> > > +{
> > > + struct sockaddr_xdp sxdp = {};
> > > + struct xdp_mmap_offsets off;
> > > + struct xsk_socket *xsk;
> > > + socklen_t optlen;
> > > + void *map;
> > > + int err;
> > > +
> > > + if (!umem || !xsk_ptr || !rx || !tx)
> > > + return -EFAULT;
> > > +
> > > + if (umem->refcount) {
> > > + pr_warning("Error: shared umems not supported by libbpf.\n");
> > > + return -EBUSY;
> > > + }
> > > +
> > > + xsk = calloc(1, sizeof(*xsk));
> > > + if (!xsk)
> > > + return -ENOMEM;
> > > +
> > > + if (umem->refcount++ > 0) {
> >
> > Should this refcount rather be atomic actually?
>
> Neither our config nor data plane interfaces are reentrant for
> performance reasons. Any concurrency has to be handled explicitly on
> the application level. This so that it only penalizes apps that really
> need this.
>
> Thanks for all your reviews: Magnus
>
> > > + xsk->fd = socket(AF_XDP, SOCK_RAW, 0);
> > > + if (xsk->fd < 0) {
> > > + err = -errno;
> > > + goto out_xsk_alloc;
> > > + }
> > > + } else {
> > > + xsk->fd = umem->fd;
> > > + }
> > > +
> > > + xsk->outstanding_tx = 0;
> > > + xsk->queue_id = queue_id;
> > > + xsk->umem = umem;
> > > + xsk->ifindex = if_nametoindex(ifname);
> > > + if (!xsk->ifindex) {
> > > + err = -errno;
> > > + goto out_socket;
> > > + }
> > > +
> > > + xsk_set_xdp_socket_config(&xsk->config, usr_config);
> > [...]
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: add support for bridge flags
From: Russell King - ARM Linux admin @ 2019-02-18 11:23 UTC (permalink / raw)
To: Florian Fainelli; +Cc: Andrew Lunn, Vivien Didelot, David S. Miller, netdev
In-Reply-To: <20190218005031.wqj54o6ilqfng5nb@shell.armlinux.org.uk>
On Mon, Feb 18, 2019 at 12:50:31AM +0000, Russell King - ARM Linux admin wrote:
> From what I can see, the port_vlan_add()/port_vlan_del() implementation
> is far from ideal, just like "always enabling flooding for CPU/DSA
> ports" is not ideal.
There also seems to be a discrepency between what net/dsa wants to do
and some of the implementations in drivers/net/dsa:
dsa_switch_vlan_add() does this:
bitmap_zero(ds->bitmap, ds->num_ports);
if (ds->index == info->sw_index)
set_bit(info->port, ds->bitmap);
for (port = 0; port < ds->num_ports; port++)
if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port))
set_bit(port, ds->bitmap);
We then call ds->ops->port_vlan_add() for each port in ds->bitmap,
which will include DSA and CPU ports on every switch in the tree.
For rtl8366, this calls into rtl8366_vlan_add(), which does:
if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port))
dev_err(smi->dev, "port is DSA or CPU port\n");
which is surely a guaranteed error message if we have any CPU or DSA
ports specified on a rtl8366. The example in the DT documentation
for this driver does suggest that it is capable of having CPU ports.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Russell King - ARM Linux admin @ 2019-02-18 11:28 UTC (permalink / raw)
To: Stefan Chulski
Cc: Antoine Tenart, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, gregory.clement@bootlin.com,
miquel.raynal@bootlin.com, Nadav Haklai, Yan Markman,
mw@semihalf.com
In-Reply-To: <DM5PR18MB1067E1DD47E7094E02043A58B0630@DM5PR18MB1067.namprd18.prod.outlook.com>
Hi Stefan,
On Mon, Feb 18, 2019 at 11:08:34AM +0000, Stefan Chulski wrote:
> HW recommendation upon Serdes reconfiguration are the following:
>
> 1. Disable port(CTRL0_REG - in XLG/GMAC)
> 2. Put port in reset (both XLG/GMAC)
> 3. For KR - put in reset MPCS (MAC control clock, RX SD clock, TX SD clock), XPSC is RXAUI/XAUI clock domain
> 4. Power down Serdes lane
>
> Do reconfiguration of Serdes.
>
> 5. Enable Serdes lane
> 6. Disable MPCS reset for KR
> 7. Disable port reset (both XLG/GMAC)
> 8. Enable port (both XLG/GMAC)
For clarity, presumably either the XLG or the GMAC should be released
from reset and enabled at any one time depending on the configured mode,
but never both together?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* RE: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS while reconfiguring the serdes lanes
From: Stefan Chulski @ 2019-02-18 11:33 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: Antoine Tenart, davem@davemloft.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
maxime.chevallier@bootlin.com, gregory.clement@bootlin.com,
miquel.raynal@bootlin.com, Nadav Haklai, Yan Markman,
mw@semihalf.com
In-Reply-To: <20190218112815.ec3pyuvzpphdance@shell.armlinux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Sent: Monday, February 18, 2019 1:28 PM
> To: Stefan Chulski <stefanc@marvell.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; davem@davemloft.net;
> netdev@vger.kernel.org; linux-kernel@vger.kernel.org;
> thomas.petazzoni@bootlin.com; maxime.chevallier@bootlin.com;
> gregory.clement@bootlin.com; miquel.raynal@bootlin.com; Nadav Haklai
> <nadavh@marvell.com>; Yan Markman <ymarkman@marvell.com>;
> mw@semihalf.com
> Subject: Re: [EXT] Re: [PATCH net-next 10/13] net: mvpp2: reset the XPCS
> while reconfiguring the serdes lanes
>
> Hi Stefan,
>
> On Mon, Feb 18, 2019 at 11:08:34AM +0000, Stefan Chulski wrote:
> > HW recommendation upon Serdes reconfiguration are the following:
> >
> > 1. Disable port(CTRL0_REG - in XLG/GMAC) 2. Put port in reset (both
> > XLG/GMAC) 3. For KR - put in reset MPCS (MAC control clock, RX SD
> > clock, TX SD clock), XPSC is RXAUI/XAUI clock domain 4. Power down
> > Serdes lane
> >
> > Do reconfiguration of Serdes.
> >
> > 5. Enable Serdes lane
> > 6. Disable MPCS reset for KR
> > 7. Disable port reset (both XLG/GMAC)
> > 8. Enable port (both XLG/GMAC)
>
> For clarity, presumably either the XLG or the GMAC should be released from
> reset and enabled at any one time depending on the configured mode, but
> never both together?
Yes.
Only one of them the XLG or the GMAC ,depending on the configured mode.
Best Regards.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] net: dsa: mv88e6xxx: fix IPv6
From: Russell King - ARM Linux admin @ 2019-02-18 11:34 UTC (permalink / raw)
To: Andrew Lunn, Florian Fainelli, Vivien Didelot; +Cc: David S. Miller, netdev
In-Reply-To: <20190217163114.yomawlljyxlqy3ob@shell.armlinux.org.uk>
On Sun, Feb 17, 2019 at 04:31:14PM +0000, Russell King - ARM Linux admin wrote:
> We have had some emails in private over this issue, this is my current
> patch set rebased on top of net-next which provides working IPv6 (and
> probably other protocols as well) over mv88e6xxx DSA switches.
>
> The problem comes down to mv88e6xxx defaulting to not flood unknown
> unicast and multicast datagrams, as they would be by dumb switches,
> and as the Linux bridge code does by default.
>
> These flood settings can be disabled via the Linux bridge code if it's
> desired to make the switch behave more like a managed switch, eg, by
> enabling the multicast querier. However, the multicast querier
> defaults to being disabled which effectively means that by default,
> mv88e6xxx switches block all multicast traffic. This is at odds with
> the Linux bridge documentation, and the defaults that the Linux bridge
> code adopts.
>
> So, this patch set adds DSA support for Linux bridge flags, adds
> mv88e6xxx support for the unicast and multicast flooding flags, and
> lastly enables flooding of these frames by default to match the
> Linux bridge defaults.
While looking at some of the other DSA drivers, I've noticed that
others are also programmed to forward unknown frames to the CPU
port. Does this not end up breaking stuff?
If I tcpdump the ethernet interface for the CPU port, what I see
is:
11:21:21.901127 00:22:68:15:37:dd (oui Unknown) > 52:54:00:00:06:25 (oui
Unknown), ethertype MEDSA (0xdada), length 126: Forward, untagged,
dev.port:vlan 0.4:0, pri 0: ethertype IPv6 (0x86dd)
e0022681537dd.dyn.armlinux.org.uk > tftp.armlinux.org.uk: ICMP6, echo
request, seq 1, length 64
which is the unknown frame being delivered to the CPU port. It seems
nothing else happens with the frame - it is ignored. Before my fixes
for mv88e6xxx, that frame (and the following frames for the same MAC
address) would end up being forwarded only to the CPU port and dropped
on the floor, never making their way to their intended destination.
It seems that "the hardware doesn't know what to do, forward it to
Linux to sort out" doesn't actually work.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH net] sock: return uapi errno in sock_setsockopt() for SO_ZEROCOPY
From: Alexey Kodanev @ 2019-02-18 11:35 UTC (permalink / raw)
To: Willem de Bruijn; +Cc: Network Development, Petr Vorel, David Miller
In-Reply-To: <CA+FuTSeRV3Qy_S3c4qayTe3K1FkaPF7cZnV7_tNVKnS3cEuxmA@mail.gmail.com>
On 15.02.2019 19:58, Willem de Bruijn wrote:
> On Fri, Feb 15, 2019 at 11:51 AM Alexey Kodanev
> <alexey.kodanev@oracle.com> wrote:
>>
>> For unsupported protocols, setsockopt() with SO_ZEROCOPY
>> option sets errno to ENOTSUPP(524). But this number is
>> not defined anywhere in the include/uapi/ headers.
>>
>> To make sure userspace sees the known number, replace
>> ENOTSUPP(524) with EOPNOTSUPP(95).
>>
>> Fixes: 76851d1212c1 ("sock: add SOCK_ZEROCOPY sockopt")
>> Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
>> Reported-by: Petr Vorel <pvorel@suse.cz>
>
> This code has been there since 4.14. I think it's too late to change
> system call behavior.
>
'ENOTSUPP' define is solely for an internal usage, it may be replaced
with another one or the number associated with it may be changed one day,
implicitly changing the behavior of setsockopt().
^ permalink raw reply
* Re: [RFC] net: dsa: qca8k: implement rgmii-id mode
From: Michal Vokáč @ 2019-02-18 11:54 UTC (permalink / raw)
To: Vinod Koul, Andrew Lunn
Cc: David S. Miller, netdev, linux-kernel@vger.kernel.org,
Florian Fainelli
In-Reply-To: <20190218104539.GL21884@vkoul-mobl>
On 18. 02. 19 11:45, Vinod Koul wrote:
> On 15-02-19, 16:23, Andrew Lunn wrote:
>> On Fri, Feb 15, 2019 at 04:01:08PM +0100, Michal Vokáč wrote:
>>> Hi,
>>>
>>> networking on my boards [1], which are currently in linux-next, suddently
>>> stopped working. I tracked it down to this commit 5ecdd77c61c8 ("net: dsa:
>>> qca8k: disable delay for RGMII mode") [2].
>>>
>>> So I think the rgmii-id mode is obviously needed in my case.
>>> I was able to find a couple drivers that read tx/rx-delay or
>>> tx/rx-internal-delay from device tree. Namely:
>>>
>>> drivers/net/ethernet/apm/xgene/xgene_enet_main.c
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
>>> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
>>> drivers/net/phy/dp83867.c
>>>
>>> I would appreciate any hints how to add similar function to qca8k driver
>>> if that is the correct way to go. Can I take some of the above mentioned
>>> drivers as a good example for that? How should the binding look like?
>>>
>>> I would expect something like this:
>>>
>>> switch@0 {
>>> compatible = "qca,qca8334";
>>> reg = <0>;
>>>
>>> switch_ports: ports {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> ethphy0: port@0 {
>>> reg = <0>;
>>> label = "cpu";
>>> phy-mode = "rgmii-id";
>>> qca,tx-delay = <3>;
>>> qca,rx-delay = <3>;
>>> ethernet = <&fec>;
>>> };
>>
>> Hi Michal
>>
>> Your submission used:
>>
>> + ethphy0: port@0 {
>> + reg = <0>;
>> + label = "cpu";
>> + phy-mode = "rgmii";
>> + ethernet = <&fec>;
>> +
>> + fixed-link {
>> + speed = <1000>;
>> + full-duplex;
>> + };
>> + };
>>
>> This is good. If you have a fixed-link you can pass a phy-mode.
Yes, I am using fixed-link and the plan was to implement the rgmii-id
mode.
>>
>> The comment that was removed was:
>>
>> - /* According to the datasheet, RGMII delay is enabled through
>> - * PORT5_PAD_CTRL for all ports, rather than individual port
>> - * registers
>> - */
>>
>> Is it possible to enable delays per port? Ideally, you want to enable
>> delays for just selected ports. Add another case for
>> PHY_INTERFACE_MODE_RGMII_ID to enable the delays.
I am still trying to collect all the relevant notes and bits from the
horrible docs to understand how this is done. The problem is different
parts and different versions of the documentation provide diffrerent
details.
For example the QCA8334 model does not have PORT5 and so that registers
are not documented. Though some application note document says:
"""
The MAC0 timing control is in the Port0 PAD Mode Control Register (offset 0x0004):
1. RGMII timing delay for the output path of QCA8337(N) is enabled by 0x8[24].
Set 1 to add 2ns delay in 1000 mode for all RGMII interfaces.
2. Bit [21:20]: select the delay time for the output path in 10/100 mode.
3. Bit 25: enable the timing delay for the input path of QCA8337(N) in 1000 mode.
4. Bit [23:22]: select the delay time for the input path in 1000 mode.
00: 0.2ns
01: 1.2ns
10: 2.1ns
11: 3.1ns
"""
That is in line with the removed comment. The bit 24 at address 0x8 is
used to enable/disable delays globally. And obviously it is needed on the
QCA8334 model as well even though it should not have the PORT5.
> In the hindsight I should not have removed the comment, let me ressurect
> that as well as add handling of the RGMII modes...
OK, thanks.
> Please do test
Sure, will do. Just let me know when you have something ready.
Thank you!
Michal
^ permalink raw reply
* Re: [PATCH] net: sched: matchall: verify that filter is not NULL in mall_walk()
From: Vlad Buslov @ 2019-02-18 12:00 UTC (permalink / raw)
To: Cong Wang
Cc: Ido Schimmel, Linux Kernel Network Developers, Jamal Hadi Salim,
Jiri Pirko, David Miller
In-Reply-To: <CAM_iQpW4WD2KpQM344DLjtzUYamR9-r398qYev1c=kgFLJhu5A@mail.gmail.com>
On Sat 16 Feb 2019 at 00:24, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Fri, Feb 15, 2019 at 4:11 AM Vlad Buslov <vladbu@mellanox.com> wrote:
>>
>> Check that filter is not NULL before passing it to tcf_walker->fn()
>> callback. This can happen when mall_change() failed to offload filter to
>> hardware.
>>
>> Signed-off-by: Vlad Buslov <vladbu@mellanox.com>
>> ---
>> net/sched/cls_matchall.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/net/sched/cls_matchall.c b/net/sched/cls_matchall.c
>> index a37137430e61..1f9d481b0fbb 100644
>> --- a/net/sched/cls_matchall.c
>> +++ b/net/sched/cls_matchall.c
>> @@ -247,6 +247,9 @@ static void mall_walk(struct tcf_proto *tp, struct tcf_walker *arg,
>>
>> if (arg->count < arg->skip)
>> goto skip;
>> +
>> + if (!head)
>> + return;
>
> So head==NULL still counts one given that you check NULL after
> checking arg->count. Is this expected?
My intention was to fix the problem (arg->fn() call with NULL filter)
without changing any other functionality, and always incrementing
arg->count once seemed to be the intended behavior. However, since
mall_delete() just returns -EOPNOTSUPP, it might be the case that author
of matchall expected to always have single filter configured when cls
API calls mall_walk(). What would you suggest?
^ permalink raw reply
* [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
From: YueHaibing @ 2019-02-18 12:19 UTC (permalink / raw)
To: Ariel Elior, Sudarsana Kalluru, David S . Miller
Cc: YueHaibing, GR-everest-linux-l2, netdev, kernel-janitors
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function 'bnx2x_get_hwinfo':
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11940:10: warning:
variable 'mfw_vn' set but not used [-Wunused-but-set-variable]
It's never used since introduction.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 3b5b47e98c73..7c47be215a34 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -11998,7 +11998,7 @@ static void validate_set_si_mode(struct bnx2x *bp)
static int bnx2x_get_hwinfo(struct bnx2x *bp)
{
int /*abs*/func = BP_ABS_FUNC(bp);
- int vn, mfw_vn;
+ int vn;
u32 val = 0, val2 = 0;
int rc = 0;
@@ -12083,12 +12083,10 @@ static int bnx2x_get_hwinfo(struct bnx2x *bp)
/*
* Initialize MF configuration
*/
-
bp->mf_ov = 0;
bp->mf_mode = 0;
bp->mf_sub_mode = 0;
vn = BP_VN(bp);
- mfw_vn = BP_FW_MB_IDX(bp);
if (!CHIP_IS_E1(bp) && !BP_NOMCP(bp)) {
BNX2X_DEV_INFO("shmem2base 0x%x, size %d, mfcfg offset %d\n",
^ permalink raw reply related
* Re: [PATCH] tcp: Namespace-ify sysctl_tcp_rmem and sysctl_tcp_wmem
From: Greg KH @ 2019-02-18 12:22 UTC (permalink / raw)
To: Alakesh Haloi
Cc: stable, David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Eric Dumazet, netdev, linux-kernel
In-Reply-To: <20190214011159.GA35034@dev-dsk-alakeshh-2c-f8a3e6e0.us-west-2.amazon.com>
On Thu, Feb 14, 2019 at 01:12:08AM +0000, Alakesh Haloi wrote:
> [ Upstream commit 356d1833b638bd465672aefeb71def3ab93fc17d ]
>
> Note that when a new netns is created, it inherits its
> sysctl_tcp_rmem and sysctl_tcp_wmem from initial netns.
>
> This change is needed so that we can refine TCP rcvbuf autotuning,
> to take RTT into consideration.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Wei Wang <weiwan@google.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> [alakeshh: backport to v4.14: The patch does not apply to v4.14
> directly and hence needed manual backport. Function signature for
> the function tcp_select_initial_window had to be changed to be able
> to pass pointer to struct sock.]
> Signed-off-by: Alakesh Haloi <alakeshh@amazon.com>
Like Sasha said, why is this needed in 4.14.y? It looks like a new
feature. What is keeping you from just using 4.19.y if you want this
feature?
thanks,
greg k-h
^ permalink raw reply
* [RFC v2] net: bridge: don't flood known multicast traffic when snooping is enabled
From: Nikolay Aleksandrov @ 2019-02-18 12:21 UTC (permalink / raw)
To: netdev
Cc: roopa, linus.luessing, idosch, f.fainelli, bridge,
Nikolay Aleksandrov
In-Reply-To: <20190215130427.29824-1-nikolay@cumulusnetworks.com>
This is v2 of the RFC patch which aims to forward packets to known
mdsts' ports only (the no querier case). After v1 I've kept
the previous behaviour when it comes to unregistered traffic or when
a querier is present. All of this is of course only with snooping
enabled. So with this patch the following changes should occur:
- No querier: forward known mdst traffic to its registered ports,
no change about unknown mcast (flood)
- Querier present: no change
The reason to do this is simple - we want to respect the user's mdb
configuration in both cases, that is if the user adds static mdb entries
manually then we should use that information about forwarding traffic.
What do you think ?
* Notes
Traffic that is currently marked as mrouters_only:
- IPv4: non-local mcast traffic, igmp reports
- IPv6: non-all-nodes-dst mcast traffic, mldv1 reports
Simple use case:
$ echo 1 > /sys/class/net/bridge/bridge/multicast_snooping
$ bridge mdb add dev bridge port swp1 grp 239.0.0.1
- without a querier currently traffic for 239.0.0.1 will still be flooded,
with this change it will be forwarded only to swp1
Ido, I know this doesn't solve the issue you brought up, maybe we should
have a separate discussion about acting on querier changes in the switch
driver or alternative solutions (e.g. always-flood-unknown-mcast knob).
Perhaps the bridge can notify the drivers on querier state changes.
This patch is meant about discussing the best way to solve the issue,
it's not thoroughly tested, in case we settle about the details I'll run
more tests.
Thanks,
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
net/bridge/br_device.c | 5 +++--
net/bridge/br_input.c | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 013323b6dbe4..e8c01409a7e7 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -96,8 +96,9 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
}
mdst = br_mdb_get(br, skb, vid);
- if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
- br_multicast_querier_exists(br, eth_hdr(skb)))
+ if (mdst ||
+ (BR_INPUT_SKB_CB_MROUTERS_ONLY(skb) &&
+ br_multicast_querier_exists(br, eth_hdr(skb))))
br_multicast_flood(mdst, skb, false, true);
else
br_flood(br, skb, BR_PKT_MULTICAST, false, true);
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 5ea7e56119c1..8777566f7b6d 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -136,8 +136,9 @@ int br_handle_frame_finish(struct net *net, struct sock *sk, struct sk_buff *skb
switch (pkt_type) {
case BR_PKT_MULTICAST:
mdst = br_mdb_get(br, skb, vid);
- if ((mdst || BR_INPUT_SKB_CB_MROUTERS_ONLY(skb)) &&
- br_multicast_querier_exists(br, eth_hdr(skb))) {
+ if (mdst ||
+ (BR_INPUT_SKB_CB_MROUTERS_ONLY(skb) &&
+ br_multicast_querier_exists(br, eth_hdr(skb)))) {
if ((mdst && mdst->host_joined) ||
br_multicast_is_router(br)) {
local_rcv = true;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next] net: sched: potential NULL dereference in tcf_block_find()
From: Vlad Buslov @ 2019-02-18 12:26 UTC (permalink / raw)
To: Dan Carpenter
Cc: Jamal Hadi Salim, Cong Wang, Jiri Pirko, David S. Miller,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20190218092632.GB7712@kadam>
On Mon 18 Feb 2019 at 09:26, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The error code isn't set on this path so it would result in returning
> ERR_PTR(0) and a NULL dereference in the caller.
>
> Fixes: 18d3eefb17cf ("net: sched: refactor tcf_block_find() into standalone functions")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Hi Dan,
Thank you for finding and fixing this!
Regards,
Vlad
^ permalink raw reply
* Re: [PATCH net-next v6] ipmr: ip6mr: Create new sockopt to clear mfc cache or vifs
From: Nikolay Aleksandrov @ 2019-02-18 12:31 UTC (permalink / raw)
To: Callum Sinclair, davem, kuznet, yoshfuji, netdev, linux-kernel
Cc: nicolas.dichtel
In-Reply-To: <20190217210752.20914-2-callum.sinclair@alliedtelesis.co.nz>
On 17/02/2019 23:07, Callum Sinclair wrote:
> Currently the only way to clear the forwarding cache was to delete the
> entries one by one using the MRT_DEL_MFC socket option or to destroy and
> recreate the socket.
>
> Create a new socket option which with the use of optional flags can
> clear any combination of multicast entries (static or not static) and
> multicast vifs (static or not static).
>
> Calling the new socket option MRT_FLUSH with the flags MRT_FLUSH_MFC and
> MRT_FLUSH_VIFS will clear all entries and vifs on the socket except for
> static entries.
>
> Signed-off-by: Callum Sinclair <callum.sinclair@alliedtelesis.co.nz>
> ---
> v1 -> v2:
> Implemented additional flags for static entries
> v2 -> v3:
> Cleaned up flag logic so any combination of routes can be cleared.
> Fixed style errors
> Fixed incorrect flag values
> v3 -> v4:
> Fixed style errors
> Fixed incorrect flag (MRT_FLUSH was used instead of MRT_FLUSH_VIFS)
> v4 -> v5:
> Only clear the unresolved queue when MRT_FLUSH_MFC flag is set.
> v5 -> v6:
> Renamed MRT6_FLUSH_VIFS to MRT6_FLUSH_MIFS
>
> include/uapi/linux/mroute.h | 9 ++++-
> include/uapi/linux/mroute6.h | 9 ++++-
> net/ipv4/ipmr.c | 75 +++++++++++++++++++++-------------
> net/ipv6/ip6mr.c | 78 +++++++++++++++++++++++-------------
> 4 files changed, 115 insertions(+), 56 deletions(-)
>
Looks good to me,
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: stmmac / meson8b-dwmac
From: Simon Huelck @ 2019-02-18 12:33 UTC (permalink / raw)
To: Jose Abreu, Martin Blumenstingl
Cc: Emiliano Ingrassia, Gpeppe.cavallaro, alexandre.torgue,
linux-amlogic, netdev
In-Reply-To: <c80c1e5b-fed9-25ce-eb1b-258ac0135ce7@synopsys.com>
Hi,
i recognize the followin on my ethernet stats:
threshold: 1
tx_pkt_n: 1457325
rx_pkt_n: 5022405
normal_irq_n: 671738
rx_normal_irq_n: 606573
napi_poll: 784439
tx_normal_irq_n: 61061
tx_clean: 784439
tx_set_ic_bit: 58293
irq_receive_pmt_irq_n: 0
mmc_tx_irq_n: 0
mmc_rx_irq_n: 0
mmc_rx_csum_offload_irq_n: 0
-> irq_tx_path_in_lpi_mode_n: 382037
-> irq_tx_path_exit_lpi_mode_n: 382021
Is this normal ?
regards,
Simon
Am 18.02.2019 um 09:45 schrieb Jose Abreu:
> On 2/18/2019 8:42 AM, Jose Abreu wrote:
>> On 2/17/2019 2:48 PM, Martin Blumenstingl wrote:
>>> Jose, is my command for disabling offloading correct?
>> Yes, I think so. What about NIC statistics and logs ? ("ethtool
>> -S eth0", "dmesg | grep -i stmmac")
> And, "ifconfig eth0" after running the test.
>
>> Thanks,
>> Jose Miguel Abreu
>>
^ 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