* RE: netdev carrier changes is one even after ethernet link up.
From: Bhadram Varka @ 2017-09-04 5:10 UTC (permalink / raw)
To: Florian Fainelli, andrew@lunn.ch; +Cc: linux-netdev
In-Reply-To: <a7bf6cf0-c534-95f9-47f6-ee56a95fe961@gmail.com>
> -----Original Message-----
> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> Sent: Saturday, September 02, 2017 7:25 AM
> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> Cc: linux-netdev <netdev@vger.kernel.org>
> Subject: Re: netdev carrier changes is one even after ethernet link up.
>
> On 08/31/2017 10:49 PM, Bhadram Varka wrote:
> > Thanks for responding. Now responding inline
> >
> >> -----Original Message-----
> >> From: Florian Fainelli [mailto:f.fainelli@gmail.com]
> >> Sent: Friday, September 01, 2017 5:53 AM
> >> To: Bhadram Varka <vbhadram@nvidia.com>; andrew@lunn.ch
> >> Cc: linux-netdev <netdev@vger.kernel.org>
> >> Subject: Re: netdev carrier changes is one even after ethernet link up.
> >>
> >> On 08/30/2017 10:53 PM, Bhadram Varka wrote:
> >>> Hi,
> >>>
> >>>
> >>>
> >>> I have observed that carrier_changes is one even in case of the
> >>> ethernet link is up.
> >>>
> >>>
> >>>
> >>> After investigating the code below is my observation -
> >>>
> >>>
> >>>
> >>> ethernet_driver_probe()
> >>>
> >>> +--->phy_connect()
> >>>
> >>> | +--->phy_attach_direct()
> >>>
> >>> | +---> netif_carrier_off() : which increments
> >>> carrier_changes to one.
> >>>
> >>> +--->register_netdevice() : will the carrier_changes becomes zero here ?
> >>>
> >>> +--->netif_carrier_off(): not increment the carrier_changes since
> >>> __LINK_STATE_NOCARRIER already set.
> >>>
> >>>
> >>>
> >>> From ethernet driver open will start the PHY and trigger the
> >>> phy_state_machine.
> >>>
> >>> Phy_state_machine workqueue calling netif_carrier_on() once the link
> >>> is
> >> UP.
> >>>
> >>> netif_carrier_on() increments the carrier_changes by one.
> >>
> >> If the call trace is correct, then there is at least two problems here:
> >>
> >> - phy_connect() does start the PHY machine which means that as soon
> >> as it detects a link state of any kind (up or down) it can call
> >> netif_carrier_off() respectively netif_carrier_on()
> >>
> >> - as soon as you call register_netdevice() notifiers run and other
> >> parts of the kernel or user-space programs can see an inconsistent
> >> link state
> >>
> >> I would suggest doing the following sequence instead:
> >>
> >> netif_carrier_off()
> >> register_netdevice()
> >> phy_connect()
> >>
> >> Which should result in a consistent link state and carrier value.
> >>
> > Yes, It will address the issue.
> >
> > If we did the phy_conect in ndo_open it will make the carrier changes as
> two. But if we did in probe function then it's not working.
> >
> > In ethernet driver probe - (below sequence is not working)
> > phy_connect()
> > register_netdevice()
> > netif_carrier_off()
> >
> > working sequence:
> > In probe():
> > register_netdevice()
> > ndo_open:
> > phy_connect()
> >
> > After reverting - https://lkml.org/lkml/2016/1/9/173 this works if we do
> phy_connect in probe as well.
>
> But as mentioned before you should not be doing the PHY probe in your
> driver's probe function for different reasons:
>
> - the probe function's responsibility is to initialize the driver and the HW to a
> state where they both have everything needed but it should be in quiesced
> state. There is no guarantee that your network device may ever be used
> after probe unless something calls ndo_open(), you should therefore keep
> all resources to a minimum: memory allocated, HW powered down etc.
>
> - there is a race condition between the PHY state machine started in
> phy_connect(), and when register_netdevice() is called and notifiers running
> which can lead to an inconsistent state for the carrier
Agreed. But I could see lot of drivers performing the phy_connect() in driver_probe() function itself.
Also observed that these drivers are performing netif_carrier_off() after register_netdevice().
My point is that why do we need to do netif_carrier_off() in phy_connect() since we already doing the same after register_netdevice() in MAC driver ?
Thanks!
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the rockchip tree
From: Stephen Rothwell @ 2017-09-04 5:26 UTC (permalink / raw)
To: David Miller, Networking, Heiko Stuebner, Olof Johansson,
Arnd Bergmann, ARM
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, David Wu,
Rocky Hao, Joseph Chen
In-Reply-To: <20170822112414.06f3b00f@canb.auug.org.au>
Hi all,
On Tue, 22 Aug 2017 11:24:14 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> arch/arm64/boot/dts/rockchip/rk3328-evb.dts
>
> between commits:
>
> ab78718bda79 ("arm64: dts: rockchip: Enable tsadc module on RK3328 eavluation board")
> 1e28037ec88e ("arm64: dts: rockchip: add rk805 node for rk3328-evb")
>
> from the rockchip tree and commit:
>
> 4b05bc6157eb ("ARM64: dts: rockchip: Enable gmac2phy for rk3328-evb")
>
> 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.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> index 86605ae7b6f5,b9f36dad17e6..000000000000
> --- a/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-evb.dts
> @@@ -51,147 -51,24 +51,164 @@@
> stdout-path = "serial2:1500000n8";
> };
>
> + dc_12v: dc-12v {
> + compatible = "regulator-fixed";
> + regulator-name = "dc_12v";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + vcc_phy: vcc-phy-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_phy";
> + regulator-always-on;
> + regulator-boot-on;
> + };
> ++
> + vcc_sys: vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&dc_12v>;
> + };
> };
>
> + &gmac2phy {
> + phy-supply = <&vcc_phy>;
> + clock_in_out = "output";
> + assigned-clocks = <&cru SCLK_MAC2PHY_SRC>;
> + assigned-clock-rate = <50000000>;
> + assigned-clocks = <&cru SCLK_MAC2PHY>;
> + assigned-clock-parents = <&cru SCLK_MAC2PHY_SRC>;
> + status = "okay";
> + };
> +
> +&i2c1 {
> + status = "okay";
> +
> + rk805: rk805@18 {
> + compatible = "rockchip,rk805";
> + reg = <0x18>;
> + interrupt-parent = <&gpio2>;
> + interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
> + #clock-cells = <1>;
> + clock-output-names = "xin32k", "rk805-clkout2";
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int_l>;
> + rockchip,system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc_sys>;
> + vcc2-supply = <&vcc_sys>;
> + vcc3-supply = <&vcc_sys>;
> + vcc4-supply = <&vcc_sys>;
> + vcc5-supply = <&vcc_io>;
> + vcc6-supply = <&vcc_io>;
> +
> + regulators {
> + vdd_logic: DCDC_REG1 {
> + regulator-name = "vdd_logic";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> +
> + vdd_arm: DCDC_REG2 {
> + regulator-name = "vdd_arm";
> + regulator-min-microvolt = <712500>;
> + regulator-max-microvolt = <1450000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <950000>;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vcc_io: DCDC_REG4 {
> + regulator-name = "vcc_io";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <3300000>;
> + };
> + };
> +
> + vcc_18: LDO_REG1 {
> + regulator-name = "vcc_18";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vcc18_emmc: LDO_REG2 {
> + regulator-name = "vcc18_emmc";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1800000>;
> + };
> + };
> +
> + vdd_10: LDO_REG3 {
> + regulator-name = "vdd_10";
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt = <1000000>;
> + };
> + };
> + };
> + };
> +};
> +
> +&pinctrl {
> + pmic {
> + pmic_int_l: pmic-int-l {
> + rockchip,pins = <2 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
> + };
> + };
> +};
> +
> +&tsadc {
> + status = "okay";
> +};
> +
> &uart2 {
> status = "okay";
> };
Just a reminder that these conflicts still exist.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH][next] rocker: fix kcalloc parameter order
From: Zahari Doychev @ 2017-09-04 5:40 UTC (permalink / raw)
To: Zahari Doychev; +Cc: jiri, netdev
In-Reply-To: <4d8a3c58c2a4e89319034f5faf41ba4682dc15ae.1504461594.git.zahari.doychev@linux.com>
On Sun, Sep 03, 2017 at 10:26:03PM +0200, Zahari Doychev wrote:
> The function calls to kcalloc use wrong parameter order. The flags
> have to be passed as last parameter.
>
> The change was done using the following coccinelle script:
>
> @@
> expression E1,E2;
> type T;
> @@
>
> -kcalloc(E1, E2, sizeof(T))
> +kcalloc(E2, sizeof(T), E1)
>
> Signed-off-by: Zahari Doychev <zahari.doychev@linux.com>
> ---
> drivers/net/ethernet/rocker/rocker_ofdpa.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/rocker/rocker_ofdpa.c b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> index da4e26b53a52..2708451ce22a 100644
> --- a/drivers/net/ethernet/rocker/rocker_ofdpa.c
> +++ b/drivers/net/ethernet/rocker/rocker_ofdpa.c
> @@ -1177,7 +1177,7 @@ static int ofdpa_group_l2_fan_out(struct ofdpa_port *ofdpa_port,
> entry->group_id = group_id;
> entry->group_count = group_count;
>
> - entry->group_ids = kcalloc(flags, group_count, sizeof(u32));
> + entry->group_ids = kcalloc(group_count, sizeof(u32), flags);
I think that the flags are also not used correctly, so I will have to resend
the patch.
> if (!entry->group_ids) {
> kfree(entry);
> return -ENOMEM;
> @@ -1456,7 +1456,7 @@ static int ofdpa_port_vlan_flood_group(struct ofdpa_port *ofdpa_port,
> int err = 0;
> int i;
>
> - group_ids = kcalloc(flags, port_count, sizeof(u32));
> + group_ids = kcalloc(port_count, sizeof(u32), flags);
> if (!group_ids)
> return -ENOMEM;
>
> --
> 2.13.0
>
^ permalink raw reply
* [PATCH net-next] cxgb4: fix memory leak
From: Ganesh Goudar @ 2017-09-04 5:46 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar
do not reuse the loop counter which is used iterate over
the ports, so that sched_tbl will be freed for all the ports.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/sched.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sched.c b/drivers/net/ethernet/chelsio/cxgb4/sched.c
index 02acff7..9148abb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sched.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sched.c
@@ -533,10 +533,10 @@ struct sched_table *t4_init_sched(unsigned int sched_size)
void t4_cleanup_sched(struct adapter *adap)
{
struct sched_table *s;
- unsigned int i;
+ unsigned int j, i;
- for_each_port(adap, i) {
- struct port_info *pi = netdev2pinfo(adap->port[i]);
+ for_each_port(adap, j) {
+ struct port_info *pi = netdev2pinfo(adap->port[j]);
s = pi->sched_tbl;
for (i = 0; i < s->sched_size; i++) {
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] cxgb4: Fix pause frame count in t4_get_port_stats
From: Ganesh Goudar @ 2017-09-04 5:47 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Casey Leedom
MPS_STAT_CTL[CountPauseStatTx] and MPS_STAT_CTL[CountPauseStatRx]
only control whether or not Pause Frames will be counted as part
of the 64-Byte Tx/Rx Frame counters. These bits do not control
whether Pause Frames are counted in the Total Tx/Rx Frames/Bytes
counters.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index b0f9aea..b65ce26 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -6001,10 +6001,8 @@ void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p)
p->tx_ppp7 = GET_STAT(TX_PORT_PPP7);
if (CHELSIO_CHIP_VERSION(adap->params.chip) >= CHELSIO_T5) {
- if (stat_ctl & COUNTPAUSESTATTX_F) {
- p->tx_frames -= p->tx_pause;
- p->tx_octets -= p->tx_pause * 64;
- }
+ if (stat_ctl & COUNTPAUSESTATTX_F)
+ p->tx_frames_64 -= p->tx_pause;
if (stat_ctl & COUNTPAUSEMCTX_F)
p->tx_mcast_frames -= p->tx_pause;
}
@@ -6037,10 +6035,8 @@ void t4_get_port_stats(struct adapter *adap, int idx, struct port_stats *p)
p->rx_ppp7 = GET_STAT(RX_PORT_PPP7);
if (CHELSIO_CHIP_VERSION(adap->params.chip) >= CHELSIO_T5) {
- if (stat_ctl & COUNTPAUSESTATRX_F) {
- p->rx_frames -= p->rx_pause;
- p->rx_octets -= p->rx_pause * 64;
- }
+ if (stat_ctl & COUNTPAUSESTATRX_F)
+ p->rx_frames_64 -= p->rx_pause;
if (stat_ctl & COUNTPAUSEMCRX_F)
p->rx_mcast_frames -= p->rx_pause;
}
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 2/3] dt-binding: net: sfp binding documentation
From: Baruch Siach @ 2017-09-04 5:55 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Rob Herring, Mark Rutland, Andrew Lunn, Florian Fainelli,
David S. Miller, netdev, devicetree, Sergei Shtylyov
In-Reply-To: <20170903204634.GZ20805@n2100.armlinux.org.uk>
Hi Russell,
On Sun, Sep 03, 2017 at 09:46:35PM +0100, Russell King - ARM Linux wrote:
> On Sun, Sep 03, 2017 at 03:31:13PM +0300, Baruch Siach wrote:
> > Add device-tree binding documentation SFP transceivers. Support for SFP
> > transceivers has been recently introduced (drivers/net/phy/sfp.c).
> >
> > Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> > ---
> > v3:
> > Mention gpios phandle and specifier
> > Mention the polarity of each gpio
> > Fix example property names
> >
> > v2:
> > Rename -gpio properties to -gpios
> > Rename the rate-select-gpio property to rate-select0-gpios
> > Add the rate-select1-gpios property
> > Add examples
> > ---
> > Documentation/devicetree/bindings/net/sff,sfp.txt | 78 +++++++++++++++++++++++
> > 1 file changed, 78 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/sff,sfp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt
> > new file mode 100644
> > index 000000000000..b98ee5945265
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt
> > @@ -0,0 +1,78 @@
> > +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> > +Transceiver
> > +
> > +Required properties:
> > +
> > +- compatible : must be "sff,sfp"
> > +
> > +Optional Properties:
> > +
> > +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> > + interface
> > +
> > +- moddef0-gpios : GPIO phandle and a single specifier of the MOD-DEF0 (AKA
> > + Mod_ABS) module presence input gpio signal, active (module absent) high
> > +
> > +- los-gpios : GPIO phandle and a single specifier of the Receiver Loss of
> > + Signal Indication input gpio signal, active (signal lost) high
> > +
> > +- tx-fault-gpios : GPIO phandle and a single specifier of the Module
> > + Transmitter Fault input gpio signal, active (fault condition) high
> > +
> > +- tx-disable-gpios : GPIO phandle and a single specifier of the Transmitter
> > + Disable output gpio signal, active (Tx disable) high
> > +
> > +- rate-select0-gpios : GPIO phandle and a single specifier of the Rx Signaling
> > + Rate Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx
> > + rate
> > +
> > +- rate-select1-gpios : GPIO phandle and a single specifier of the Tx Signaling
> > + Rate Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate,
> > + high: high Tx rate
> > +
> > +Example #1: Direct serdes to SFP connection
> > +
> > +sfp_eth3: sfp-eth3 {
> > + compatible = "sff,sfp";
> > + i2c-bus = <&sfp_1g_i2c>;
> > + los-gpios = <&cpm_gpio2 22 GPIO_ACTIVE_HIGH>;
> > + moddef0-gpios = <&cpm_gpio2 21 GPIO_ACTIVE_LOW>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&cpm_sfp_1g_pins &cps_sfp_1g_pins>;
> > + tx-disable-gpios = <&cps_gpio1 24 GPIO_ACTIVE_HIGH>;
> > + tx-fault-gpios = <&cpm_gpio2 19 GPIO_ACTIVE_HIGH>;
> > +};
> > +
> > +&cps_emac3 {
> > + phy-mode = "sgmii";
> > + phy-names = "comphy";
> > + phys = <&cps_comphy 5 COMPHY_SGMII2>;
>
> I don't like this level of example - SGMII is Cisco SGMII which is not
> the same as 1000Base-X - the two are incompatible. Fibre SFP modules
> only work with 1000Base-X.
>
> The SFP/phylink takes care of informing the MAC which mode it should
> be in, and the MAC must configure itself appropriately in response to
> that, otherwise the module can't be supported.
So, if I understand you correctly, the PHY mode should not be coded in the DT
since the mode is run-time configurable, and depends on the SFP module. Is
that correct?
How about the following then:
&cps_emac3 {
phy-names = "comphy";
phys = <&cps_comphy 5>;
sfp = <&sfp_eth3>;
};
Thanks,
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH net-next] cxgb4: Ignore MPS_TX_INT_CAUSE[Bubble] for T6
From: Ganesh Goudar @ 2017-09-04 5:55 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, venkatesh, Ganesh Goudar, Casey Leedom
MPS_TX_INT_CAUSE[Bubble] is a normal condition for T6, hence
ignore this interrupt for T6.
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 08624db..b0f9aea 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4548,6 +4548,18 @@ static void mps_intr_handler(struct adapter *adapter)
{ FRMERR_F, "MPS Tx framing error", -1, 1 },
{ 0 }
};
+ static const struct intr_info t6_mps_tx_intr_info[] = {
+ { TPFIFO_V(TPFIFO_M), "MPS Tx TP FIFO parity error", -1, 1 },
+ { NCSIFIFO_F, "MPS Tx NC-SI FIFO parity error", -1, 1 },
+ { TXDATAFIFO_V(TXDATAFIFO_M), "MPS Tx data FIFO parity error",
+ -1, 1 },
+ { TXDESCFIFO_V(TXDESCFIFO_M), "MPS Tx desc FIFO parity error",
+ -1, 1 },
+ /* MPS Tx Bubble is normal for T6 */
+ { SECNTERR_F, "MPS Tx SOP/EOP error", -1, 1 },
+ { FRMERR_F, "MPS Tx framing error", -1, 1 },
+ { 0 }
+ };
static const struct intr_info mps_trc_intr_info[] = {
{ FILTMEM_V(FILTMEM_M), "MPS TRC filter parity error", -1, 1 },
{ PKTFIFO_V(PKTFIFO_M), "MPS TRC packet FIFO parity error",
@@ -4579,7 +4591,9 @@ static void mps_intr_handler(struct adapter *adapter)
fat = t4_handle_intr_status(adapter, MPS_RX_PERR_INT_CAUSE_A,
mps_rx_intr_info) +
t4_handle_intr_status(adapter, MPS_TX_INT_CAUSE_A,
- mps_tx_intr_info) +
+ is_t6(adapter->params.chip)
+ ? t6_mps_tx_intr_info
+ : mps_tx_intr_info) +
t4_handle_intr_status(adapter, MPS_TRC_INT_CAUSE_A,
mps_trc_intr_info) +
t4_handle_intr_status(adapter, MPS_STAT_PERR_INT_CAUSE_SRAM_A,
--
2.1.0
^ permalink raw reply related
* We'll ship you a 30-day supply of our weight loss product
From: info @ 2017-09-02 8:45 UTC (permalink / raw)
To: netdev
Taking a premium quality weight loss aid solution like ours daily is simply the only way to make sure your body gets the vitamins it needs to burn excessive fat and stay active.
It was created with premium additives, our diet aid solution will help you feel amazing and look your best!
Our diet pill includes over 24 different nutrients and minerals and it helps preserve your:
Boosted metabolism,
Immune system,
Physical energy,
Muscle mass.
We will send you a 25-day supply of our weight reduction supplement only if you use this link within the next three days.
This URL is only provided for this IP
http://vztgjn.greenerpasturesip.xyz/OS8yLzIwMTc7MTA6NDU6NTI=
^ permalink raw reply
* [PATCH v3] ip6_tunnel: Correct tos value in collect_md mode
From: Haishuang Yan @ 2017-09-04 6:17 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, Peter Dawson
Same as ip_gre, geneve and vxlan, use key->tos as traffic class value.
CC: Peter Dawson <petedaws@gmail.com>
Fixes: 0e9a709560db ("ip6_tunnel, ip6_gre: fix setting of DSCP on
encapsulated packets”)
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Changes since v3:
* Add fixes information
* Remove obsoleted RT_TOS mask
---
net/ipv6/ip6_tunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index ef99d59..9d65918 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1249,7 +1249,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPIP;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
if (!(t->parms.flags & IP6_TNL_F_IGN_ENCAP_LIMIT))
encap_limit = t->parms.encap_limit;
@@ -1320,7 +1320,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
fl6.flowi6_proto = IPPROTO_IPV6;
fl6.daddr = key->u.ipv6.dst;
fl6.flowlabel = key->label;
- dsfield = ip6_tclass(key->label);
+ dsfield = key->tos;
} else {
offset = ip6_tnl_parse_tlv_enc_lim(skb, skb_network_header(skb));
/* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head */
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] ip6_tunnel: fix setting hop_limit value for ipv6 tunnel
From: Haishuang Yan @ 2017-09-04 6:17 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan
In-Reply-To: <1504505848-3331-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
Similar to vxlan/geneve tunnel, if hop_limit is zero, it should fall
back to ip6_dst_hoplimt().
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
net/ipv6/ip6_tunnel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 3a0ba2a..10a693a 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -1184,6 +1184,7 @@ int ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev, __u8 dsfield,
init_tel_txopt(&opt, encap_limit);
ipv6_push_frag_opts(skb, &opt.ops, &proto);
}
+ hop_limit = hop_limit ? : ip6_dst_hoplimit(dst);
/* Calculate max headroom for all the headers and adjust
* needed_headroom if necessary.
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next 1/1] sched: Use __qdisc_drop instead of kfree_skb in sch_prio and sch_qfq
From: gfree.wind @ 2017-09-04 6:21 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem, edumazet, netdev; +Cc: Gao Feng
From: Gao Feng <gfree.wind@vip.163.com>
The commit 520ac30f4551 ("net_sched: drop packets after root qdisc lock
is released) made a big change of tc for performance. There are two points
left in sch_prio and sch_qfq which are not changed with that commit. Now
enhance them now with __qdisc_drop.
Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
---
net/sched/sch_prio.c | 2 +-
net/sched/sch_qfq.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_prio.c b/net/sched/sch_prio.c
index f31b28f..2dd6c68 100644
--- a/net/sched/sch_prio.c
+++ b/net/sched/sch_prio.c
@@ -80,7 +80,7 @@ struct prio_sched_data {
if (ret & __NET_XMIT_BYPASS)
qdisc_qstats_drop(sch);
- kfree_skb(skb);
+ __qdisc_drop(skb, to_free);
return ret;
}
#endif
diff --git a/net/sched/sch_qfq.c b/net/sched/sch_qfq.c
index cd661a7..6ddfd49 100644
--- a/net/sched/sch_qfq.c
+++ b/net/sched/sch_qfq.c
@@ -1215,7 +1215,7 @@ static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch,
if (cl == NULL) {
if (err & __NET_XMIT_BYPASS)
qdisc_qstats_drop(sch);
- kfree_skb(skb);
+ __qdisc_drop(skb, to_free);
return err;
}
pr_debug("qfq_enqueue: cl = %x\n", cl->common.classid);
--
1.9.1
^ permalink raw reply related
* [net v2] gianfar: Fix Tx flow control deactivation
From: Claudiu Manoil @ 2017-09-04 7:45 UTC (permalink / raw)
To: netdev; +Cc: David S . Miller
The wrong register is checked for the Tx flow control bit,
it should have been maccfg1 not maccfg2.
This went unnoticed for so long probably because the impact is
hardly visible, not to mention the tangled code from adjust_link().
First, link flow control (i.e. handling of Rx/Tx link level pause frames)
is disabled by default (needs to be enabled via 'ethtool -A').
Secondly, maccfg2 always returns 0 for tx_flow_oldval (except for a few
old boards), which results in Tx flow control remaining always on
once activated.
Should be queued for -stable, thanks.
Fixes: 45b679c9a3ccd9e34f28e6ec677b812a860eb8eb ("gianfar: Implement PAUSE frame generation support")
Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
---
v2: "Fixes" tag formatting and removed CC: stable from comments.
drivers/net/ethernet/freescale/gianfar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index c4b4b0a..5be52d8 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -3687,7 +3687,7 @@ static noinline void gfar_update_link_state(struct gfar_private *priv)
u32 tempval1 = gfar_read(®s->maccfg1);
u32 tempval = gfar_read(®s->maccfg2);
u32 ecntrl = gfar_read(®s->ecntrl);
- u32 tx_flow_oldval = (tempval & MACCFG1_TX_FLOW);
+ u32 tx_flow_oldval = (tempval1 & MACCFG1_TX_FLOW);
if (phydev->duplex != priv->oldduplex) {
if (!(phydev->duplex))
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/4] bpf: add helper bpf_perf_read_counter_time for perf event array map
From: Peter Zijlstra @ 2017-09-04 7:46 UTC (permalink / raw)
To: Yonghong Song; +Cc: rostedt, ast, daniel, netdev, kernel-team
In-Reply-To: <20170902054824.371962-2-yhs@fb.com>
On Fri, Sep 01, 2017 at 10:48:21PM -0700, Yonghong Song wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index b14095b..5a50808 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -898,7 +898,8 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr,
> void *context);
> extern void perf_pmu_migrate_context(struct pmu *pmu,
> int src_cpu, int dst_cpu);
> -int perf_event_read_local(struct perf_event *event, u64 *value);
> +int perf_event_read_local(struct perf_event *event, u64 *value,
> + u64 *enabled, u64 *running);
> extern u64 perf_event_read_value(struct perf_event *event,
> u64 *enabled, u64 *running);
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 8c01572..20c4039 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3670,7 +3670,8 @@ static inline u64 perf_event_count(struct perf_event *event)
> * will not be local and we cannot read them atomically
> * - must not have a pmu::count method
> */
> -int perf_event_read_local(struct perf_event *event, u64 *value)
> +int perf_event_read_local(struct perf_event *event, u64 *value,
> + u64 *enabled, u64 *running)
> {
> unsigned long flags;
> int ret = 0;
> @@ -3694,7 +3695,7 @@ int perf_event_read_local(struct perf_event *event, u64 *value)
> * It must not have a pmu::count method, those are not
> * NMI safe.
> */
> - if (event->pmu->count) {
> + if (value && event->pmu->count) {
> ret = -EOPNOTSUPP;
> goto out;
> }
No, value _must_ be !NULL. Otherwise you allow getting timestamps
independently from the count value and that is broken.
The {value, enabled, running} tuple is temporally related.
> @@ -3718,10 +3719,16 @@ int perf_event_read_local(struct perf_event *event, u64 *value)
> * or local to this CPU. Furthermore it means its ACTIVE (otherwise
> * oncpu == -1).
> */
> - if (event->oncpu == smp_processor_id())
> - event->pmu->read(event);
> -
> - *value = local64_read(&event->count);
> + if (value) {
> + if (event->oncpu == smp_processor_id())
> + event->pmu->read(event);
> + *value = local64_read(&event->count);
> + }
> + if (enabled && running) {
> + u64 ctx_time = event->shadow_ctx_time + perf_clock();
> + *enabled = ctx_time - event->tstamp_enabled;
> + *running = ctx_time - event->tstamp_running;
> + }
> out:
> local_irq_restore(flags);
Please make that something like:
u64 now = event->shadow_ctx_time + perf_clock();
if (enabled)
*enabled = now - event->tstamp_enabled;
if (event->oncpu == smp_processor_id()) {
event->pmu->read(event);
if (running)
*running = now - event->tstamp_running;
} else {
*running = event->total_time_running;
}
And I'll fix it up when I make:
https://lkml.kernel.org/r/20170831171837.njnc6r6elsvkl7lt@hirez.programming.kicks-ass.net
happen.
^ permalink raw reply
* Re: [PATCH net-next v7] openvswitch: enable NSH support
From: Yang, Yi @ 2017-09-04 8:00 UTC (permalink / raw)
To: Jiri Benc
Cc: netdev@vger.kernel.org, davem@davemloft.net, dev@openvswitch.org,
e@erig.me, blp@ovn.org, jan.scheurich@ericsson.com
In-Reply-To: <20170831124516.0c5db686@griffin>
On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> > + mask->context[i]);
> > + }
> > + memcpy(flow_key->nsh.context, nsh->md1.context,
> > + sizeof(nsh->md1.context));
>
> Do you follow the discussion that Hannes Sowa started on the ovs list
> regarding matching on the context fields? It would be better to hold on this
> until there's a conclusion reached.
>
I think we have had similiar discussion about this, the issue is we have
no way to handle both MD type 1 and MD type 2 by using a common flow key struct.
So we have to do so, there is miniflow to handle such issue in
userspace, but kernel data path didn't provide such mechanism. I think
every newly-added key will result in the same space-wasting issue for
kernel data path, isn't it?
> > + err = nsh_key_from_nlattr(&attr.nla, &nsh);
> > + if (err)
> > + break;
> > + err = nsh_key_from_nlattr(&mask.nla, &nsh_mask);
> > + if (err)
> > + break;
>
> This is a lot of copying to just be able to use nla_for_each_nested. While
> I'm not a fan of how ovs uses the attributes to store both value and mask,
> it's not completely irrational. However, I don't think that the intent was
> to store a copy of the whole nested group. It's quite obvious that it does
> not fit the pattern from the gymnastics you need to do.
>
> Instead, store the mask in each of the nested attributes individually. There
> will be no need for the copying above and the code will get cleaner and
> faster. It's not that the nsh_key_from_nlattr function needs to be able to
> work separately for the key and mask. Nothing else than the line above uses
> this function. Just move the logic inside.
>
> Actually, it seems it can be moved directly to set_nsh.
OVS_ATTR_KEY_NSH is the first case to use nested attributes for set
action, so no reference code for this, set action has two use cases, one
has mask but the other hasn't, so it will be easier an nested attribute is
handled as a whole, in user space, nsh_key_from_nlattr is used in
several places. If we change it per your proposal, there will be a lot
of rework, we have to provide two functions to handle this, one is for
the case with mask, the other is for the case without mask.
>
> > + err = set_nsh(skb, flow_key, &nsh, &nsh_mask);
> > + break;
> > + }
> > +
> > case OVS_KEY_ATTR_IPV4:
> > err = set_ipv4(skb, flow_key, nla_data(a),
> > get_mask(a, struct ovs_key_ipv4 *));
> > @@ -1210,6 +1336,21 @@ static int do_execute_actions(struct datapath *dp, struct sk_buff *skb,
> > case OVS_ACTION_ATTR_POP_ETH:
> > err = pop_eth(skb, key);
> > break;
> > +
> > + case OVS_ACTION_ATTR_PUSH_NSH: {
> > + u8 buffer[NSH_HDR_MAX_LEN];
> > + struct nshhdr *nsh_hdr = (struct nshhdr *)buffer;
> > + const struct nshhdr *nsh_src = nsh_hdr;
> > +
> > + nsh_hdr_from_nlattr(nla_data(a), nsh_hdr,
> > + NSH_HDR_MAX_LEN);
>
> This is costly. This is called for every packet in the fast path. We should
> precompute and store the header instead.
How can we do so? I see batch process code in user space implementation,
but kernel data path didn't such infrastructure, how can we know next
push_nsh uses the same nsh header as previous one?
> > + case NSH_M_TYPE2:
> > + /* Don't support MD type 2 metedata parsing yet */
> > + if (length < NSH_BASE_HDR_LEN)
> > + return -EINVAL;
>
> Shouldn't we reject the packet, then? Pretending that something was parsed
> correctly while in fact it was not, does not look correct.
For MD type 2, we don't implement metadata parsing, but it can still
work. I'm not sure what you mean here, how do we reject a packet here?
>
> These checks should be done only once when the action is configured, not for
> each packet.
I don't know how to implement a batch processing in kernel data path, it
seems there isn't such code for reference.
^ permalink raw reply
* Re: [PATCH] mm/vmstats: add counters for the page frag cache
From: Konstantin Khlebnikov @ 2017-09-04 8:30 UTC (permalink / raw)
To: Kyeongdon Kim, akpm, sfr
Cc: ying.huang, vbabka, hannes, xieyisheng1, luto, shli, mhocko,
mgorman, hillf.zj, kemi.wang, rientjes, bigeasy, iamjoonsoo.kim,
bongkyu.kim, linux-kernel, linux-mm, netdev
In-Reply-To: <19156a13-6153-f570-317b-7b80505347e7@lge.com>
On 04.09.2017 04:35, Kyeongdon Kim wrote:
> Thanks for your reply,
> But I couldn't find "NR_FRAGMENT_PAGES" in linux-next.git .. is that vmstat counter? or others?
>
I mean rather than adding bunch vmstat counters for operations it might be
worth to add page counter which will show current amount of these pages.
But this seems too low-level for tracking, common counters for all network
buffers would be more useful but much harder to implement.
As I can see page owner is able to save stacktrace where allocation happened,
this makes debugging mostly trivial without any counters. If it adds too much
overhead - just track random 1% of pages, should be enough for finding leak.
> As you know, page_frag_alloc() directly calls __alloc_pages_nodemask() function,
> so that makes too difficult to see memory usage in real time even though we have "/meminfo or /slabinfo.." information.
> If there was a way already to figure out the memory leakage from page_frag_cache in mainline, I agree your opinion
> but I think we don't have it now.
>
> If those counters too much in my patch,
> I can say two values (pgfrag_alloc and pgfrag_free) are enough to guess what will happen
> and would remove pgfrag_alloc_calls and pgfrag_free_calls.
>
> Thanks,
> Kyeongdon Kim
>
> On 2017-09-01 오후 6:12, Konstantin Khlebnikov wrote:
>> IMHO that's too much counters.
>> Per-node NR_FRAGMENT_PAGES should be enough for guessing what's going on.
>> Perf probes provides enough features for furhter debugging.
>>
>> On 01.09.2017 02:37, Kyeongdon Kim wrote:
>> > There was a memory leak problem when we did stressful test
>> > on Android device.
>> > The root cause of this was from page_frag_cache alloc
>> > and it was very hard to find out.
>> >
>> > We add to count the page frag allocation and free with function call.
>> > The gap between pgfrag_alloc and pgfrag_free is good to to calculate
>> > for the amount of page.
>> > The gap between pgfrag_alloc_calls and pgfrag_free_calls is for
>> > sub-indicator.
>> > They can see trends of memory usage during the test.
>> > Without it, it's difficult to check page frag usage so I believe we
>> > should add it.
>> >
>> > Signed-off-by: Kyeongdon Kim <kyeongdon.kim@lge.com>
>> > ---
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v3 1/2] ip_tunnel: fix ip tunnel lookup in collect_md mode
From: Haishuang Yan @ 2017-09-04 8:36 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, Pravin B Shelar
In collect_md mode, if the tun dev is down, it still can call
ip_tunnel_rcv to receive on packets, and the rx statistics increase
improperly.
Fixes: 2e15ea390e6f ("ip_gre: Add support to collect tunnel metadata.")
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Change since v3:
* Increment rx_dropped if tunnel device is not up, suggested by
Pravin B Shelar
* Fix wrong recipient addresss
---
net/ipv4/ip_tunnel.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index e1856bf..5b2e542 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -176,8 +176,11 @@ struct ip_tunnel *ip_tunnel_lookup(struct ip_tunnel_net *itn,
return cand;
t = rcu_dereference(itn->collect_md_tun);
- if (t)
- return t;
+ if (t) {
+ if (t->dev->flags & IFF_UP)
+ return t;
+ t->dev->stats.rx_dropped++;
+ }
if (itn->fb_tunnel_dev && itn->fb_tunnel_dev->flags & IFF_UP)
return netdev_priv(itn->fb_tunnel_dev);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 2/2] ip6_tunnel: fix ip6 tunnel lookup in collect_md mode
From: Haishuang Yan @ 2017-09-04 8:36 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI
Cc: netdev, linux-kernel, Haishuang Yan, Alexei Starovoitov
In-Reply-To: <1504514174-14958-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
In collect_md mode, if the tun dev is down, it still can call
__ip6_tnl_rcv to receive on packets, and the rx statistics increase
improperly.
Fixes: 8d79266bc48c ("ip6_tunnel: add collect_md mode to IPv6 tunnels")
Cc: Alexei Starovoitov <ast@fb.com>
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
---
Change since v3:
* Increment rx_dropped if tunnel device is not up, suggested by
Pravin B Shelar
* Fix wrong recipient address
---
net/ipv6/ip6_tunnel.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 10a693a..e91d3b6 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -171,8 +171,11 @@ static struct net_device_stats *ip6_get_stats(struct net_device *dev)
}
t = rcu_dereference(ip6n->collect_md_tun);
- if (t)
- return t;
+ if (t) {
+ if (t->dev->flags & IFF_UP)
+ return t;
+ t->dev->stats.rx_dropped++;
+ }
t = rcu_dereference(ip6n->tnls_wc[0]);
if (t && (t->dev->flags & IFF_UP))
--
1.8.3.1
^ permalink raw reply related
* [PATCH net-next v7] net: stmmac: Delete dead code for MDIO registration
From: Romain Perier @ 2017-09-04 8:41 UTC (permalink / raw)
To: Giuseppe Cavallaro, Alexandre Torgue, Andrew Lunn,
Florian Fainelli
Cc: David S. Miller, netdev, linux-kernel, Romain Perier
This code is no longer used, the logging function was changed by commit
fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register").
It was previously showing information about the type of the IRQ, if it's
polled, ignored or a normal interrupt. As we don't want information loss,
I have moved this code to phy_attached_print().
Fixes: fbca164776e4 ("net: stmmac: Use the right logging function in stmmac_mdio_register")
Signed-off-by: Romain Perier <romain.perier@collabora.com>
---
Hello,
This is the continuity of "[PATCH v2 0/2] net: stmmac: phy logging fixes",
see https://lkml.org/lkml/2017/8/21/288
Changes in v7:
- Rebased onto net-next
Changes in v6:
- Rebased onto net-next
Changes in v5:
- Don't truncater commit fbca164776e4 in the message of *this* commit
- Fixed typo
Changes in v4:
- Don't truncate the commit subject for "Fixes"
- Fixed invalid sizeof() used with snprintf
- Added "net-next" prefix to the title of the commit
Changes in v3:
- Removed patch 2/2: "net: phy: Don't use drv when it is NULL in phy_attached_print",
fixed upstream by fcd03e362b1c
("net: phy: Deal with unbound PHY driver in phy_attached_print()")
- Moved this code to phy_attached_print(), so we have more informations
about the IRQ (poll, ignore or normal irq) and no information are loss.
- Re-worded commit message
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 16 ----------------
drivers/net/phy/phy_device.c | 22 +++++++++++++++++++---
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index 72ec711fcba2..f5f37bfa1d58 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -248,9 +248,6 @@ int stmmac_mdio_register(struct net_device *ndev)
found = 0;
for (addr = 0; addr < PHY_MAX_ADDR; addr++) {
struct phy_device *phydev = mdiobus_get_phy(new_bus, addr);
- int act = 0;
- char irq_num[4];
- char *irq_str;
if (!phydev)
continue;
@@ -273,19 +270,6 @@ int stmmac_mdio_register(struct net_device *ndev)
if (priv->plat->phy_addr == -1)
priv->plat->phy_addr = addr;
- act = (priv->plat->phy_addr == addr);
- switch (phydev->irq) {
- case PHY_POLL:
- irq_str = "POLL";
- break;
- case PHY_IGNORE_INTERRUPT:
- irq_str = "IGNORE";
- break;
- default:
- sprintf(irq_num, "%d", phydev->irq);
- irq_str = irq_num;
- break;
- }
phy_attached_info(phydev);
found = 1;
}
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 810f6fd2f639..8cf0c5901f95 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -874,21 +874,37 @@ void phy_attached_info(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_attached_info);
-#define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)"
+#define ATTACHED_FMT "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%s)"
void phy_attached_print(struct phy_device *phydev, const char *fmt, ...)
{
const char *drv_name = phydev->drv ? phydev->drv->name : "unbound";
+ char *irq_str;
+ char irq_num[4];
+
+ switch(phydev->irq) {
+ case PHY_POLL:
+ irq_str = "POLL";
+ break;
+ case PHY_IGNORE_INTERRUPT:
+ irq_str = "IGNORE";
+ break;
+ default:
+ snprintf(irq_num, sizeof(irq_num), "%d", phydev->irq);
+ irq_str = irq_num;
+ break;
+ }
+
if (!fmt) {
dev_info(&phydev->mdio.dev, ATTACHED_FMT "\n",
drv_name, phydev_name(phydev),
- phydev->irq);
+ irq_str);
} else {
va_list ap;
dev_info(&phydev->mdio.dev, ATTACHED_FMT,
drv_name, phydev_name(phydev),
- phydev->irq);
+ irq_str);
va_start(ap, fmt);
vprintk(fmt, ap);
--
2.11.0
^ permalink raw reply related
* Re: netdev watchdog enp1s0 (tg3): transmit queue 0 timed out
From: Siva Reddy Kallam @ 2017-09-04 9:09 UTC (permalink / raw)
To: Frans van Berckel; +Cc: Michael Chan, linux-netdev
On Fri, Sep 1, 2017 at 12:13 PM, Frans van Berckel <fberckel@xs4all.nl> wrote:
> Dear Michael and Siva,
>
> On Thu, 2017-08-31 at 23:36 -0700, Michael Chan wrote:
>> On Thu, Aug 31, 2017 at 11:10 PM, Frans van Berckel
>> <fberckel@xs4all.nl> wrote:
>> >
>> > <snap> a long list of likely the same type of error codes.
>> >
>>
>> Please post the entire register dump.
>
> [ 237.169194] tg3 0000:01:00.0 enp1s0: Link is up at 1000 Mbps, full
> duplex
> [ 237.169335] tg3 0000:01:00.0 enp1s0: Flow control is on for TX and
> on for RX
> [ 237.169375] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes
> ready
> [ 243.683910] tg3 0000:01:00.0 enp1s0: DMA Status error. Resetting
> chip.
> [ 243.759610] hrtimer: interrupt took 9464192 ns
> [ 245.317566] tg3 0000:01:00.0 enp1s0: 0x00000000: 0x165914e4,
> 0x00100406, 0x02000021, 0x00000010
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000010: 0xefcf0004,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000020: 0x00000000,
> 0x00000000, 0x00000000, 0x01eb1028
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000030: 0x00000000,
> 0x00000048, 0x00000000, 0x00000105
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000040: 0x00000000,
> 0x00000000, 0xc0025001, 0x64002000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000050: 0x00fc5803,
> 0x80818283, 0x0087d005, 0xfee0300c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000060: 0x00000000,
> 0x00004122, 0x42010298, 0x76180000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000070: 0x000010f2,
> 0x000000a0, 0x00000000, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000080: 0x165914e4,
> 0x3c1d0002, 0x04130034, 0x3c085082
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000090: 0x01009509,
> 0x00000000, 0x00000000, 0x000000ce
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000000a0: 0x00000000,
> 0x00000006, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000000b0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000000c0: 0x00000000,
> 0x00000000, 0x0000000e, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000000d0: 0x00010010,
> 0x00000fa0, 0x00122104, 0x00036c11
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000000e0: 0x10110000,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000100: 0x13c10001,
> 0x00014000, 0x0011c000, 0x000e3010
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000110: 0x00000000,
> 0x000011c1, 0x000000a0, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000130: 0x00000000,
> 0x00000000, 0x00000000, 0x16010002
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000150: 0x800000ff,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000160: 0x16c10003,
> 0xfe3b2547, 0x001ec9ff, 0x00010004
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000170: 0x00000000,
> 0x0007810e, 0x00000001, 0x2c0c3c0e
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000180: 0x3f062304,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000200: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000210: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000220: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000230: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000240: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000250: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000260: 0x00000000,
> 0x00000001, 0x00000000, 0x000000ce
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000270: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000280: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000290: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002a0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002b0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002c0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002d0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002e0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000002f0: 0x00000000,
> 0x00000006, 0x00000000, 0x00000006
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000300: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000310: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000320: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000330: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000340: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000350: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000360: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000370: 0x00000000,
> 0x0000000f, 0x00000000, 0x0000000f
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000380: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000390: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003a0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003b0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003c0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003d0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003e0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x000003f0: 0x00000000,
> 0x0000000c, 0x00000000, 0x0000000c
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000400: 0x00e04808,
> 0x00400000, 0x00001000, 0x00000880
> [ 245.476295] tg3 0000:01:00.0 enp1s0: 0x00000410: 0x0000001e,
> 0xc93b2547, 0x0000001e, 0xc93b2547
> [ 245.502584] tg3 0000:01:00.0 enp1s0: 0x00000420: 0x0000001e,
> 0xc93b2547, 0x0000001e, 0xc93b2547
> [ 245.504134] tg3 0000:01:00.0 enp1s0: 0x00000430: 0x00000000,
> 0x00000000, 0x000002f8, 0x000005f2
> [ 245.505060] tg3 0000:01:00.0 enp1s0: 0x00000440: 0x00000000,
> 0x00000000, 0x00000000, 0x08310301
> [ 245.506073] tg3 0000:01:00.0 enp1s0: 0x00000450: 0x00000001,
> 0x000c0000, 0x00000000, 0x00000012
> [ 245.508062] tg3 0000:01:00.0 enp1s0: 0x00000460: 0x00000008,
> 0x00002620, 0x00000006, 0x00000000
> [ 245.509057] tg3 0000:01:00.0 enp1s0: 0x00000470: 0xa0000080,
> 0x00000000, 0x00000000, 0x50000000
> [ 245.510120] tg3 0000:01:00.0 enp1s0: 0x00000480: 0x42000000,
> 0x7fffffff, 0x06000004, 0x7fffffff
> [ 245.512072] tg3 0000:01:00.0 enp1s0: 0x00000500: 0x00000008,
> 0x00000002, 0x00000000, 0x00000000
> [ 245.513052] tg3 0000:01:00.0 enp1s0: 0x00000590: 0x01e00000,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.514132] tg3 0000:01:00.0 enp1s0: 0x00000600: 0xffffffff,
> 0x00f80011, 0x00000000, 0x00001f04
> [ 245.516108] tg3 0000:01:00.0 enp1s0: 0x00000610: 0xffffffff,
> 0x00000000, 0x07c00004, 0x36ecf800
> [ 245.517074] tg3 0000:01:00.0 enp1s0: 0x00000620: 0x00000040,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.518121] tg3 0000:01:00.0 enp1s0: 0x00000800: 0x00000000,
> 0xffffffff, 0x00000000, 0x00000000
> [ 245.520060] tg3 0000:01:00.0 enp1s0: 0x00000810: 0x00000000,
> 0xffffffff, 0x00000000, 0x00000000
> [ 245.521077] tg3 0000:01:00.0 enp1s0: 0x00000820: 0x00000000,
> 0x00000000, 0xffffffff, 0x00000000
> [ 245.523047] tg3 0000:01:00.0 enp1s0: 0x00000830: 0x00000000,
> 0xffffffff, 0xffffffff, 0xffffffff
> [ 245.524073] tg3 0000:01:00.0 enp1s0: 0x00000840: 0xffffffff,
> 0xffffffff, 0xffffffff, 0xffffffff
> [ 245.525063] tg3 0000:01:00.0 enp1s0: 0x00000850: 0xffffffff,
> 0xffffffff, 0xffffffff, 0xffffffff
> [ 245.527048] tg3 0000:01:00.0 enp1s0: 0x00000860: 0xffffffff,
> 0xffffffff, 0xffffffff, 0x00000000
> [ 245.528073] tg3 0000:01:00.0 enp1s0: 0x00000880: 0x00000040,
> 0x000001a8, 0x00000000, 0x00000001
> [ 245.529070] tg3 0000:01:00.0 enp1s0: 0x000008f0: 0x00000001,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.530174] tg3 0000:01:00.0 enp1s0: 0x00000c00: 0x0000000a,
> 0x00000000, 0x00000003, 0x00000001
> [ 245.532064] tg3 0000:01:00.0 enp1s0: 0x00000c10: 0x00000000,
> 0x00000000, 0x00000000, 0x004d0000
> [ 245.533072] tg3 0000:01:00.0 enp1s0: 0x00000c80: 0x0000000c,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.534079] tg3 0000:01:00.0 enp1s0: 0x00000ce0: 0x790cb002,
> 0x00000000, 0x0000004d, 0x00041028
> [ 245.536073] tg3 0000:01:00.0 enp1s0: 0x00000cf0: 0x00000000,
> 0x5000000c, 0x00000000, 0x00000000
> [ 245.537070] tg3 0000:01:00.0 enp1s0: 0x00001000: 0x00000002,
> 0x00000000, 0xa0000618, 0x00000000
> [ 245.539096] tg3 0000:01:00.0 enp1s0: 0x00001010: 0x000c00c0,
> 0x00000618, 0x00000000, 0x00000000
> [ 245.540065] tg3 0000:01:00.0 enp1s0: 0x00001400: 0x00000006,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.542048] tg3 0000:01:00.0 enp1s0: 0x00001440: 0x0000000c,
> 0x0000000c, 0x0000000c, 0x0000000c
> [ 245.543056] tg3 0000:01:00.0 enp1s0: 0x00001450: 0x0000000c,
> 0x0000000c, 0x0000000c, 0x0000000c
> [ 245.544064] tg3 0000:01:00.0 enp1s0: 0x00001460: 0x0000000c,
> 0x0000000c, 0x0000000c, 0x0000000c
> [ 245.546056] tg3 0000:01:00.0 enp1s0: 0x00001470: 0x0000000c,
> 0x0000000c, 0x0000000c, 0x0000000c
> [ 245.548047] tg3 0000:01:00.0 enp1s0: 0x00001480: 0x00000001,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.549060] tg3 0000:01:00.0 enp1s0: 0x00001800: 0x00000016,
> 0x00000000, 0x0000000d, 0x00000000
> [ 245.551128] tg3 0000:01:00.0 enp1s0: 0x00001840: 0x00000000,
> 0x00000000, 0x00000710, 0x00000010
> [ 245.552065] tg3 0000:01:00.0 enp1s0: 0x00001850: 0x752260d0,
> 0x00000000, 0x000040d0, 0x000d000e
> [ 245.554053] tg3 0000:01:00.0 enp1s0: 0x00001860: 0x01000100,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.555073] tg3 0000:01:00.0 enp1s0: 0x00001c00: 0x00000002,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.557059] tg3 0000:01:00.0 enp1s0: 0x00002000: 0x00000002,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.559055] tg3 0000:01:00.0 enp1s0: 0x00002010: 0x00000181,
> 0x00000001, 0x00790807, 0x00000000
> [ 245.560071] tg3 0000:01:00.0 enp1s0: 0x00002100: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.562058] tg3 0000:01:00.0 enp1s0: 0x00002110: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.564065] tg3 0000:01:00.0 enp1s0: 0x00002120: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.566127] tg3 0000:01:00.0 enp1s0: 0x00002130: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.567066] tg3 0000:01:00.0 enp1s0: 0x00002140: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.569055] tg3 0000:01:00.0 enp1s0: 0x00002150: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.571063] tg3 0000:01:00.0 enp1s0: 0x00002160: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.573128] tg3 0000:01:00.0 enp1s0: 0x00002170: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.574065] tg3 0000:01:00.0 enp1s0: 0x00002180: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.576057] tg3 0000:01:00.0 enp1s0: 0x00002190: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.578063] tg3 0000:01:00.0 enp1s0: 0x000021a0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.580060] tg3 0000:01:00.0 enp1s0: 0x000021b0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.582128] tg3 0000:01:00.0 enp1s0: 0x000021c0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.583057] tg3 0000:01:00.0 enp1s0: 0x000021d0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.585055] tg3 0000:01:00.0 enp1s0: 0x000021e0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.587060] tg3 0000:01:00.0 enp1s0: 0x000021f0: 0x000c6c36,
> 0x000c6c36, 0x00000000, 0x00000000
> [ 245.589126] tg3 0000:01:00.0 enp1s0: 0x00002200: 0x00000009,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.590057] tg3 0000:01:00.0 enp1s0: 0x00002400: 0x00000012,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.592058] tg3 0000:01:00.0 enp1s0: 0x00002450: 0x00000000,
> 0x74b1c000, 0x02000000, 0x00006000
> [ 245.594128] tg3 0000:01:00.0 enp1s0: 0x00002470: 0x00000000,
> 0x00000007, 0x00000000, 0x00000000
> [ 245.595057] tg3 0000:01:00.0 enp1s0: 0x000024c0: 0x08000001,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.597062] tg3 0000:01:00.0 enp1s0: 0x00002800: 0x00000006,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.599128] tg3 0000:01:00.0 enp1s0: 0x00002c00: 0x00000006,
> 0x00000000, 0x00000000, 0x0000007f
> [ 245.600064] tg3 0000:01:00.0 enp1s0: 0x00002c10: 0x00000000,
> 0x00000000, 0x00000008, 0x00000000
> [ 245.602066] tg3 0000:01:00.0 enp1s0: 0x00002c20: 0x00000001,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.603057] tg3 0000:01:00.0 enp1s0: 0x00003000: 0x00000006,
> 0x00000000, 0x00000000, 0x0000007f
> [ 245.605064] tg3 0000:01:00.0 enp1s0: 0x00003c00: 0x00000302,
> 0x00000000, 0x00000014, 0x00000048
> [ 245.606056] tg3 0000:01:00.0 enp1s0: 0x00003c10: 0x00000005,
> 0x00000035, 0x00000000, 0x00000000
> [ 245.608059] tg3 0000:01:00.0 enp1s0: 0x00003c20: 0x00000005,
> 0x00000005, 0x00000000, 0x00000000
> [ 245.610128] tg3 0000:01:00.0 enp1s0: 0x00003c30: 0x00000000,
> 0x00000000, 0x00000000, 0x73e53000
> [ 245.611065] tg3 0000:01:00.0 enp1s0: 0x00003c40: 0x00000000,
> 0x00000b00, 0x00000000, 0x00000000
> [ 245.613128] tg3 0000:01:00.0 enp1s0: 0x00003c50: 0x00000000,
> 0x00000007, 0x00000000, 0x00000000
> [ 245.614060] tg3 0000:01:00.0 enp1s0: 0x00003c80: 0x00000007,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.616070] tg3 0000:01:00.0 enp1s0: 0x00003cc0: 0x0000000c,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.617061] tg3 0000:01:00.0 enp1s0: 0x00004000: 0x00000002,
> 0x00000000, 0x001ebffc, 0x001635cf
> [ 245.619063] tg3 0000:01:00.0 enp1s0: 0x00004010: 0x004186a0,
> 0x00236012, 0x00800440, 0x01001862
> [ 245.620062] tg3 0000:01:00.0 enp1s0: 0x00004020: 0x0020eb11,
> 0x00000000, 0x00000010, 0x00000000
> [ 245.622067] tg3 0000:01:00.0 enp1s0: 0x00004030: 0x00000010,
> 0x00000030, 0x00000000, 0x00000000
> [ 245.623060] tg3 0000:01:00.0 enp1s0: 0x00004040: 0x00000000,
> 0x00000000, 0x01081620, 0x00000000
> [ 245.625060] tg3 0000:01:00.0 enp1s0: 0x00004050: 0x00000000,
> 0x00000000, 0x00236010, 0x00413002
> [ 245.626060] tg3 0000:01:00.0 enp1s0: 0x00004060: 0x00419000,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.628066] tg3 0000:01:00.0 enp1s0: 0x00004400: 0x00000006,
> 0x00000000, 0x00011080, 0x0000df80
> [ 245.630096] tg3 0000:01:00.0 enp1s0: 0x00004410: 0x00000000,
> 0x00000010, 0x00000060, 0x00000000
> [ 245.631066] tg3 0000:01:00.0 enp1s0: 0x00004420: 0x0000003d,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.633129] tg3 0000:01:00.0 enp1s0: 0x00004440: 0x00000000,
> 0x00000000, 0x00000000, 0x0180601a
> [ 245.634062] tg3 0000:01:00.0 enp1s0: 0x00004450: 0x000103be,
> 0x00160017, 0x00000000, 0x00000000
> [ 245.636063] tg3 0000:01:00.0 enp1s0: 0x00004800: 0x080303fe,
> 0x00000010, 0x01000019, 0x00000020
> [ 245.637054] tg3 0000:01:00.0 enp1s0: 0x00004810: 0x00000011,
> 0x00000004, 0x00000000, 0x00000004
> [ 245.639064] tg3 0000:01:00.0 enp1s0: 0x00004820: 0x00100019,
> 0x00000000, 0xa0a40010, 0x752260c0
> [ 245.641128] tg3 0000:01:00.0 enp1s0: 0x00004830: 0x00000010,
> 0x000000e4, 0x000000e4, 0x00000000
> [ 245.642055] tg3 0000:01:00.0 enp1s0: 0x00004840: 0x0000000c,
> 0x0000000c, 0x030e2200, 0x192a3f66
> [ 245.644065] tg3 0000:01:00.0 enp1s0: 0x00004850: 0xffff7da7,
> 0x83b1004d, 0x13181318, 0x00000000
> [ 245.646128] tg3 0000:01:00.0 enp1s0: 0x00004c00: 0x000003fe,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.647075] tg3 0000:01:00.0 enp1s0: 0x00004c10: 0x00000000,
> 0x00000000, 0x00000006, 0x00000000
> [ 245.649061] tg3 0000:01:00.0 enp1s0: 0x00004c20: 0x00000000,
> 0x00000000, 0x00000000, 0x00000006
> [ 245.651079] tg3 0000:01:00.0 enp1s0: 0x00004c30: 0x00000000,
> 0x00000000, 0x00000056, 0x00000056
> [ 245.653047] tg3 0000:01:00.0 enp1s0: 0x00004c40: 0x00000000,
> 0x73e53000, 0x00010020, 0x00000020
> [ 245.654055] tg3 0000:01:00.0 enp1s0: 0x00005000: 0x00009800,
> 0x80004000, 0x00000000, 0x00000000
> [ 245.656071] tg3 0000:01:00.0 enp1s0: 0x00005010: 0x00000000,
> 0x00000000, 0x00000000, 0x0001081c
> [ 245.658101] tg3 0000:01:00.0 enp1s0: 0x00005020: 0x8fb20018,
> 0x00000000, 0x00000000, 0x40000020
> [ 245.659056] tg3 0000:01:00.0 enp1s0: 0x00005030: 0x00000000,
> 0x0000001d, 0x00000000, 0x00000000
> [ 245.661063] tg3 0000:01:00.0 enp1s0: 0x00005040: 0x00000000,
> 0x00000000, 0x00010dd2, 0x00000000
> [ 245.663067] tg3 0000:01:00.0 enp1s0: 0x00005200: 0x00000000,
> 0xb49a89ab, 0xfffeffff, 0x00000000
> [ 245.665055] tg3 0000:01:00.0 enp1s0: 0x00005210: 0x0001ff90,
> 0x00010820, 0x00000000, 0x0001ff90
> [ 245.667060] tg3 0000:01:00.0 enp1s0: 0x00005220: 0xb49a89ab,
> 0x00000000, 0xb49a89ab, 0x00000000
> [ 245.669071] tg3 0000:01:00.0 enp1s0: 0x00005230: 0x00000000,
> 0x00000000, 0x0001ff90, 0x00000000
> [ 245.671066] tg3 0000:01:00.0 enp1s0: 0x00005240: 0x0001ff90,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.673101] tg3 0000:01:00.0 enp1s0: 0x00005250: 0x00000000,
> 0x0001ff90, 0x00000000, 0x0001ff90
> [ 245.675092] tg3 0000:01:00.0 enp1s0: 0x00005260: 0x00000000,
> 0x0001ff90, 0x00000000, 0xb49a89ab
> [ 245.677079] tg3 0000:01:00.0 enp1s0: 0x00005270: 0x00000000,
> 0x0001ff90, 0x00010820, 0x00000000
> [ 245.679067] tg3 0000:01:00.0 enp1s0: 0x00005800: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.681070] tg3 0000:01:00.0 enp1s0: 0x00005810: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.683076] tg3 0000:01:00.0 enp1s0: 0x00005820: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.685072] tg3 0000:01:00.0 enp1s0: 0x00005830: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.687070] tg3 0000:01:00.0 enp1s0: 0x00005840: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.689073] tg3 0000:01:00.0 enp1s0: 0x00005850: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.691074] tg3 0000:01:00.0 enp1s0: 0x00005860: 0x00000000,
> 0x00000001, 0x00000000, 0x000000ce
> [ 245.693070] tg3 0000:01:00.0 enp1s0: 0x00005870: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.695068] tg3 0000:01:00.0 enp1s0: 0x00005880: 0x00000000,
> 0x00000006, 0x00000000, 0x00000001
> [ 245.697060] tg3 0000:01:00.0 enp1s0: 0x00005890: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.699057] tg3 0000:01:00.0 enp1s0: 0x000058a0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.701053] tg3 0000:01:00.0 enp1s0: 0x000058b0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.703058] tg3 0000:01:00.0 enp1s0: 0x000058c0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.705128] tg3 0000:01:00.0 enp1s0: 0x000058d0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.707128] tg3 0000:01:00.0 enp1s0: 0x000058e0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.708075] tg3 0000:01:00.0 enp1s0: 0x000058f0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.710063] tg3 0000:01:00.0 enp1s0: 0x00005900: 0x00000000,
> 0x0000000f, 0x00000000, 0x00000001
> [ 245.712060] tg3 0000:01:00.0 enp1s0: 0x00005910: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.714068] tg3 0000:01:00.0 enp1s0: 0x00005920: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.716073] tg3 0000:01:00.0 enp1s0: 0x00005930: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.718052] tg3 0000:01:00.0 enp1s0: 0x00005940: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.720081] tg3 0000:01:00.0 enp1s0: 0x00005950: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.722047] tg3 0000:01:00.0 enp1s0: 0x00005960: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.723070] tg3 0000:01:00.0 enp1s0: 0x00005970: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.725063] tg3 0000:01:00.0 enp1s0: 0x00005980: 0x00000000,
> 0x0000000c, 0x00000000, 0x00000001
> [ 245.727055] tg3 0000:01:00.0 enp1s0: 0x00005990: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.729047] tg3 0000:01:00.0 enp1s0: 0x000059a0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.730074] tg3 0000:01:00.0 enp1s0: 0x000059b0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.732060] tg3 0000:01:00.0 enp1s0: 0x000059c0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.734095] tg3 0000:01:00.0 enp1s0: 0x000059d0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.735079] tg3 0000:01:00.0 enp1s0: 0x000059e0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.737056] tg3 0000:01:00.0 enp1s0: 0x000059f0: 0x00000000,
> 0x00000001, 0x00000000, 0x00000001
> [ 245.738058] tg3 0000:01:00.0 enp1s0: 0x00005a00: 0x00012001,
> 0x00000000, 0x00010000, 0x00000000
> [ 245.740054] tg3 0000:01:00.0 enp1s0: 0x00006000: 0x00000002,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.742127] tg3 0000:01:00.0 enp1s0: 0x00006800: 0x04130034,
> 0x3c085082, 0x01009509, 0x0c502cdc
> [ 245.743051] tg3 0000:01:00.0 enp1s0: 0x00006810: 0x81120000,
> 0xffffffff, 0x00000000, 0x00000000
> [ 245.745067] tg3 0000:01:00.0 enp1s0: 0x00006830: 0xfffc3ccf,
> 0xfffc0fff, 0x00000000, 0x00000000
> [ 245.746066] tg3 0000:01:00.0 enp1s0: 0x00006840: 0x00000024,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.748061] tg3 0000:01:00.0 enp1s0: 0x00006c00: 0x00000040,
> 0x00000000, 0x00000000, 0x00000000
> [ 245.749074] tg3 0000:01:00.0 enp1s0: 0x00006c40: 0x00000000,
> 0x000f0000, 0x00000000, 0x000000f7
> [ 245.751054] tg3 0000:01:00.0 enp1s0: 0x00006c50: 0x00000000,
> 0x00000000, 0x000000f7, 0x00000000
> [ 245.753096] tg3 0000:01:00.0 enp1s0: 0x00007000: 0x00000188,
> 0x00000000, 0x00000000, 0x000000c0
> [ 245.754055] tg3 0000:01:00.0 enp1s0: 0x00007010: 0x0a000064,
> 0x02008273, 0x00570081, 0x68848353
> [ 245.756109] tg3 0000:01:00.0 enp1s0: 0x00007020: 0x00000000,
> 0x00000000, 0xaf000400, 0x00000000
> [ 245.757052] tg3 0000:01:00.0 enp1s0: 0x00007400: 0x00000000,
> 0x000000aa, 0x00000000, 0x00000000
> [ 245.759057] tg3 0000:01:00.0 enp1s0: 0x00007800: 0x00000000,
> 0x00000000, 0x00000001, 0x00000000
> [ 245.760055] tg3 0000:01:00.0 enp1s0: 0x00007810: 0x00000000,
> 0x00000060, 0x0000000d, 0x00000000
> [ 245.762065] tg3 0000:01:00.0 enp1s0: 0: Host status block
> [00000005:00000016:(0000:0007:0000):(0007:000c)]
> [ 245.764128] tg3 0000:01:00.0 enp1s0: 0: NAPI info
> [00000015:00000015:(000f:000c:01ff):0006:(00ce:0000:0000:0000)]
> [ 245.867391] tg3 0000:01:00.0: tg3_stop_block timed out, ofs=2c00
> enable_bit=2
> [ 245.971098] tg3 0000:01:00.0: tg3_stop_block timed out, ofs=4800
> enable_bit=2
> [ 245.993343] tg3 0000:01:00.0 enp1s0: Link is down
> [ 249.731158] tg3 0000:01:00.0 enp1s0: Link is up at 1000 Mbps, full
> duplex
> [ 249.731336] tg3 0000:01:00.0 enp1s0: Flow control is on for TX and
> on for RX
> [ 254.944022] ------------[ cut here ]------------
> [ 254.945010] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:316
> dev_watchdog+0x221/0x230
> [ 254.945010] NETDEV WATCHDOG: enp1s0 (tg3): transmit queue 0 timed
> out
> [ 254.945010] Modules linked in: xt_CHECKSUM ipt_MASQUERADE
> nf_nat_masquerade_ipv4 tun fuse nf_conntrack_netbios_ns
> nf_conntrack_broadcast xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
> xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge
> ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
> ip6table_mangle ip6table_raw ip6table_security iptable_nat
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
> libcrc32c iptable_mangle iptable_raw iptable_security ebtable_filter
> ebtables ip6table_filter ip6_tables powernow_k8 amd64_edac_mod
> edac_mce_amd edac_core kvm_amd kvm irqbypass amdkfd amd_iommu_v2 dcdbas
> radeon k8temp ipmi_ssif i2c_algo_bit ttm drm_kms_helper drm ipmi_si
> ipmi_devintf tpm_tis ipmi_msghandler tpm_tis_core tpm i2c_piix4 shpchp
> nls_utf8 isofs squashfs ata_generic
> [ 254.945010] pata_acpi uas usb_storage 8021q garp stp llc mrp
> serio_raw tg3 sata_sil24 ptp pps_core pata_serverworks sunrpc
> scsi_transport_iscsi loop
> [ 254.945010] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.11.8-
> 300.fc26.x86_64 #1
> [ 254.945010] Hardware name: Dell Inc. PowerEdge SC1435/0YR707, BIOS
> 2.2.5 03/21/2008
> [ 254.945010] Call Trace:
> [ 254.945010] <IRQ>
> [ 254.945010] dump_stack+0x63/0x84
> [ 254.945010] __warn+0xcb/0xf0
> [ 254.945010] warn_slowpath_fmt+0x5a/0x80
> [ 254.945010] dev_watchdog+0x221/0x230
> [ 254.945010] ? qdisc_rcu_free+0x50/0x50
> [ 254.945010] call_timer_fn+0x33/0x130
> [ 254.945010] run_timer_softirq+0x3ee/0x440
> [ 254.945010] ? ktime_get+0x40/0xb0
> [ 254.945010] ? lapic_next_event+0x1d/0x30
> [ 254.945010] __do_softirq+0xea/0x2e3
> [ 254.945010] irq_exit+0xfb/0x100
> [ 254.945010] smp_apic_timer_interrupt+0x3d/0x50
> [ 254.945010] apic_timer_interrupt+0x93/0xa0
> [ 254.945010] RIP: 0010:native_safe_halt+0x6/0x10
> [ 254.945010] RSP: 0018:ffffbabf4038be60 EFLAGS: 00000246 ORIG_RAX:
> ffffffffffffff10
> [ 254.945010] RAX: 6874754100002d40 RBX: ffff926d39d04880 RCX:
> 0000000000000000
> [ 254.945010] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> 0000000000000000
> [ 254.945010] RBP: ffffbabf4038be60 R08: ffff926d3d052ae0 R09:
> 0000000000000000
> [ 254.945010] R10: 0000000000000000 R11: 0000000000000000 R12:
> 0000000000000001
> [ 254.945010] R13: ffff926d39d04880 R14: 0000000000000000 R15:
> 0000000000000000
> [ 254.945010] </IRQ>
> [ 254.945010] default_idle+0x20/0xe0
> [ 254.945010] amd_e400_idle+0x3f/0x50
> [ 254.945010] arch_cpu_idle+0xf/0x20
> [ 254.945010] default_idle_call+0x23/0x30
> [ 254.945010] do_idle+0x170/0x200
> [ 254.945010] cpu_startup_entry+0x71/0x80
> [ 254.945010] start_secondary+0x154/0x190
> [ 254.945010] start_cpu+0x14/0x14
> [ 255.080137] ---[ end trace 25a535e6d8610c90 ]---
> [ 255.080137] tg3 0000:01:00.0 enp1s0: transmit timed out, resetting
Can you please share below commands output as well?
lspci -v
lspci -t
^ permalink raw reply
* Re: [pull request][net-next 0/3] Mellanox, mlx5 GRE tunnel offloads
From: Hannes Frederic Sowa @ 2017-09-04 9:37 UTC (permalink / raw)
To: Saeed Mahameed; +Cc: Saeed Mahameed, David S. Miller, Linux Netdev List
In-Reply-To: <CALzJLG-KgwRXODJ8BghrYzhdQYtwEM1N1UVwsg+49UiAWbb8uQ@mail.gmail.com>
Hello,
Saeed Mahameed <saeedm@dev.mellanox.co.il> writes:
[...]
> On Sat, Sep 2, 2017 at 6:32 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
>> Sorry, I think I am still confused.
>>
>> I just want to make sure that you don't use the first nibble after the
>> mpls bottom of stack label in any way as an indicator if that is an IPv4
>> or IPv6 packet by default. It can be anything. The forward equivalence
>> class tells the stack which protocol you see.
>>
>> If you match on the first nibble behind the MPLS bottom of stack label
>> the '4' or '6' respectively could be part of a MAC address with its
>> first nibble being 4 or 6, because the particular pseudowire is EoMPLS
>> and uses no control world.
>>
>> I wanted to mention it, because with addition of e.g. VPLS this could
>> cause problems down the road and should at least be controllable? It is
>> probably better to use Entropy Labels in future.
>>
>
> Hi Hannes,
>
> I see your concern now, but still it has nothing to do with the
> driver, the whole change is only to simplify driver code to not push
> full blown matching steering rules into the HW, and simply replace it
> with a one bit command.
Sorry, I very much got the impression from the cover letter plus the
descriptions of the patches.
> Regarding your concern, I will need to check with the HW guys and
> review the processing algorithm that identifies IP packets over MPLs,
> and will get back to you.
>
> if there is really a problem, then yes, we might need to make it
> controllable ..
Thanks for looking into this. I do think it can be added as a feature
but I very much think such logic should be disabled by default.
Thanks,
Hannes
^ permalink raw reply
* RE: [ovs-dev] [PATCH net-next v6 3/3] openvswitch: enable NSH support
From: Jan Scheurich @ 2017-09-04 9:38 UTC (permalink / raw)
To: Hannes Frederic Sowa, Mooney, Sean K
Cc: dev@openvswitch.org, e@erig.me, jbenc@redhat.com,
netdev@vger.kernel.org
In-Reply-To: <87d17boqb1.fsf@stressinduktion.org>
> >> >> Does it makes sense to keep the context headers as part of the flow?
> >> >> What is the reasoning behind it? With mdtype 2 headers this might
> >> >> either not work very well or will increase sw_flow_key size causing
> >> >> slowdowns for all protocols.
> >> > [Mooney, Sean K]
> >> > Having the nsh context headers in the flow is quite useful It would
> >> > allow loadblancing on values stored in the context headers Or other
> >> > use. I belive odl previously used context header 4 to store a Flow id
> >> > so this could potentialy be used with the multipath action to have
> >> ovs
> >> > Choose between several possible next hops in the chain.
> >>
> >> In OVS, masks are a list(!) for matching. How can this work for
> >> different paths that might require different masks? If they can't be
> >> unified you even get exact matches. Thus, for OVS the context should
> >> not be part of the flow.
>
> > [Mooney, Sean K] I'm not sure what you mean about a list as I never
> > made reference to one. md type 1 context headers are 4 mandatory 32
> > bit field.
>
> The semantic of the context fields depend on the path id. Every path can
> have their own interpretation of context fields.
>
> Thus the paths will cetainly have their own masks. I hope I understood
> this part of the standard correctly.
>
> dp only supports installing (approximated) disjoint megaflows and this
> affects performance a lot. Every new mask that gets added to the dp will
> be installed into a list which will be walked sequentially for
> packets. This will kill performance.
>
> I assume that user space slows down, too, depending on the algorithm
> they use generate megaflows.
The primary use case for OVS in SFC/NSH is SFF. In almost all SFF use
cases OVS will not need to match on context headers. The ability of OVS
to match on context headers should not in general slow down the datapath.
When SFC controllers match on parts of the context headers (e.g. in the
final SFF or for load-balancing purposes), we will get additional megaflow
masks. This is a fact of life in OVS and nothing new in NSH. I don't think
this should prevent us from supporting valid use cases in OVS.
The slow-down of the megaflow lookup in the datapath with the number
of masks has been addressed in the user-space datapath with sorting the
mask lists according to hit frequency and maintaining one sorted lists per
ingress port. There is further work in progress to improve on this with a
cuckoo hash to pick the most likely mask first.
It should be possible to apply similar optimization schemes also in the
Kernel datapath.
> > form an ovs context they should be treated the same as the 32 bit register fields.
> > We do not need to necessarily support those in md type 2 as all metadata is optional.
Support for matching on or updating MD2 TLV context headers is FFS in a
future OVS release. We do not foresee to add MD2 TLVs explicitly to the
flow struct.
> > You can also see that context header 1 and 2 are still used in the newer odl netvirt sfc classifier implementation
> > https://github.com/opendaylight/netvirt/blob/ba22f7cf19d8a827d77a3391a7f654344ade43d8/docs/specs/new-sfc-
> classifier.rst#pipeline-changes
> > so for odl existing nsh support to work with md type one we must have the ability to set the nsh context headers
> > and should have the ability to match on them also for load lancing between service function in service function group.
>
> As I said, a separate action sounds much more useful.
I don't think it is a good approach in OVS to introduce custom actions for NSH, e.g. for load sharing based on context header data. The primary tool for load sharing in OpenFlow is the Select Group. OVS already support an extension to the OF 1.5 Group Mod message to specify which fields to hash on. This can be used to hash on the relevant NSH context headers.
BR, Jan
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-binding: net: sfp binding documentation
From: Sergei Shtylyov @ 2017-09-04 9:59 UTC (permalink / raw)
To: Baruch Siach, Rob Herring, Mark Rutland, Andrew Lunn,
Florian Fainelli, David S. Miller, Russell King
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <01ae7bc45d68322669d18a4feeaeef733ba888d7.1504441874.git.baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Hello!
On 9/3/2017 3:31 PM, Baruch Siach wrote:
> Add device-tree binding documentation SFP transceivers. Support for SFP
> transceivers has been recently introduced (drivers/net/phy/sfp.c).
>
> Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
[...]
> diff --git a/Documentation/devicetree/bindings/net/sff,sfp.txt b/Documentation/devicetree/bindings/net/sff,sfp.txt
> new file mode 100644
> index 000000000000..b98ee5945265
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/sff,sfp.txt
> @@ -0,0 +1,78 @@
> +Small Form Factor (SFF) Committee Small Form-factor Pluggable (SFP)
> +Transceiver
> +
> +Required properties:
> +
> +- compatible : must be "sff,sfp"
> +
> +Optional Properties:
> +
> +- i2c-bus : phandle of an I2C bus controller for the SFP two wire serial
> + interface
> +
> +- moddef0-gpios : GPIO phandle and a single specifier of the MOD-DEF0 (AKA
There's always a single specifier following a phandle, tho it may have
different # of cells, no need to spell that out.
> + Mod_ABS) module presence input gpio signal, active (module absent) high
> +
> +- los-gpios : GPIO phandle and a single specifier of the Receiver Loss of
Same here.
> + Signal Indication input gpio signal, active (signal lost) high
> +
> +- tx-fault-gpios : GPIO phandle and a single specifier of the Module
And here.
> + Transmitter Fault input gpio signal, active (fault condition) high
> +
> +- tx-disable-gpios : GPIO phandle and a single specifier of the Transmitter
And here.
> + Disable output gpio signal, active (Tx disable) high
> +
> +- rate-select0-gpios : GPIO phandle and a single specifier of the Rx Signaling
Here too.
> + Rate Select (AKA RS0) output gpio signal, low: low Rx rate, high: high Rx
> + rate
> +
> +- rate-select1-gpios : GPIO phandle and a single specifier of the Tx Signaling
Here ass well.
> + Rate Select (AKA RS1) output gpio signal (SFP+ only), low: low Tx rate,
> + high: high Tx rate
> +
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 net-next 2/2] tls: Use correct sk->sk_prot for IPV6
From: Ilya Lesokhin @ 2017-09-04 10:14 UTC (permalink / raw)
To: netdev, davem; +Cc: davejwatson, aviadye, Ilya Lesokhin, Boris Pismenny
In-Reply-To: <1504520041-55634-1-git-send-email-ilyal@mellanox.com>
The tls ulp overrides sk->prot with a new tls specific proto structs.
The tls specific structs were previously based on the ipv4 specific
tcp_prot sturct.
As a result, attaching the tls ulp to an ipv6 tcp socket replaced
some ipv6 callback with the ipv4 equivalents.
This patch adds ipv6 tls proto structs and uses them when
attached to ipv6 sockets.
Fixes: 3c4d7559159b ('tls: kernel TLS support')
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
---
net/tls/Kconfig | 1 +
net/tls/tls_main.c | 50 ++++++++++++++++++++++++++++++++++++++------------
2 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/net/tls/Kconfig b/net/tls/Kconfig
index eb58303..7e9cf8b 100644
--- a/net/tls/Kconfig
+++ b/net/tls/Kconfig
@@ -7,6 +7,7 @@ config TLS
select CRYPTO
select CRYPTO_AES
select CRYPTO_GCM
+ select IPV6
default n
---help---
Enable kernel support for TLS protocol. This allows symmetric
diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
index 60aff60..33c499e 100644
--- a/net/tls/tls_main.c
+++ b/net/tls/tls_main.c
@@ -40,13 +40,25 @@
#include <linux/sched/signal.h>
#include <net/tls.h>
+#include <net/transp_v6.h>
MODULE_AUTHOR("Mellanox Technologies");
MODULE_DESCRIPTION("Transport Layer Security Support");
MODULE_LICENSE("Dual BSD/GPL");
-static struct proto tls_base_prot;
-static struct proto tls_sw_prot;
+enum {
+ TLSV4,
+ TLSV6,
+ TLS_NUM_PROTS,
+};
+
+enum {
+ TLS_BASE_TX,
+ TLS_SW_TX,
+ TLS_NUM_CONFIG,
+};
+
+static struct proto tls_prots[TLS_NUM_PROTS][TLS_NUM_CONFIG];
int wait_on_pending_writer(struct sock *sk, long *timeo)
{
@@ -342,6 +354,7 @@ static int do_tls_setsockopt_tx(struct sock *sk, char __user *optval,
struct tls_context *ctx = tls_get_ctx(sk);
struct proto *prot = NULL;
int rc = 0;
+ int ip_ver = sk->sk_family == AF_INET6 ? TLSV6 : TLSV4;
if (!optval || (optlen < sizeof(*crypto_info))) {
rc = -EINVAL;
@@ -396,7 +409,7 @@ static int do_tls_setsockopt_tx(struct sock *sk, char __user *optval,
/* currently SW is default, we will have ethtool in future */
rc = tls_set_sw_offload(sk, ctx);
- prot = &tls_sw_prot;
+ prot = &tls_prots[ip_ver][TLS_SW_TX];
if (rc)
goto err_crypto_info;
@@ -443,6 +456,12 @@ static int tls_init(struct sock *sk)
struct inet_connection_sock *icsk = inet_csk(sk);
struct tls_context *ctx;
int rc = 0;
+ int ip_ver = TLSV4;
+
+ if (sk->sk_prot == &tcpv6_prot)
+ ip_ver = TLSV6;
+ else if (sk->sk_prot != &tcp_prot)
+ return -EINVAL;
/* allocate tls context */
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -453,7 +472,8 @@ static int tls_init(struct sock *sk)
icsk->icsk_ulp_data = ctx;
ctx->setsockopt = sk->sk_prot->setsockopt;
ctx->getsockopt = sk->sk_prot->getsockopt;
- sk->sk_prot = &tls_base_prot;
+
+ sk->sk_prot = &tls_prots[ip_ver][TLS_BASE_TX];
out:
return rc;
}
@@ -464,16 +484,22 @@ static int tls_init(struct sock *sk)
.init = tls_init,
};
+static void build_protos(struct proto *prot, struct proto *base)
+{
+ prot[TLS_BASE_TX] = *base;
+ prot[TLS_BASE_TX].setsockopt = tls_setsockopt;
+ prot[TLS_BASE_TX].getsockopt = tls_getsockopt;
+
+ prot[TLS_SW_TX] = prot[TLS_BASE_TX];
+ prot[TLS_SW_TX].close = tls_sk_proto_close;
+ prot[TLS_SW_TX].sendmsg = tls_sw_sendmsg;
+ prot[TLS_SW_TX].sendpage = tls_sw_sendpage;
+}
+
static int __init tls_register(void)
{
- tls_base_prot = tcp_prot;
- tls_base_prot.setsockopt = tls_setsockopt;
- tls_base_prot.getsockopt = tls_getsockopt;
-
- tls_sw_prot = tls_base_prot;
- tls_sw_prot.sendmsg = tls_sw_sendmsg;
- tls_sw_prot.sendpage = tls_sw_sendpage;
- tls_sw_prot.close = tls_sk_proto_close;
+ build_protos(tls_prots[TLSV4], &tcp_prot);
+ build_protos(tls_prots[TLSV6], &tcpv6_prot);
tcp_register_ulp(&tcp_tls_ulp_ops);
--
1.8.3.1
^ permalink raw reply related
* [PATCH v3 net-next 0/2] Use correct sk->sk_prot for IPV6
From: Ilya Lesokhin @ 2017-09-04 10:13 UTC (permalink / raw)
To: netdev, davem; +Cc: davejwatson, aviadye, Ilya Lesokhin
The tls ulp overrides sk->prot with a new tls specific proto structs.
The tls specific structs were previously based on the ipv4 specific
tcp_prot sturct.
As a result, attaching the tls ulp to an ipv6 tcp socket replaced
some ipv6 callback with the ipv4 equivalents.
This patch adds ipv6 tls proto structs and uses them when
attached to ipv6 sockets.
Changed since v2:
- Dropped patch to fix IPV6_ADDRFORM setsockopt
There was some disagreement about the correct way of fixinig it,
and this series does not depend on it.
Changes since v1:
- TLS now dependes on IPV6
This fixes complication issues when TLS is built-in and IPV6 is a module.
The downside should be small as it is unlikely that there are kernel TLS
users who can't afford to include IPV6 in thier kernel.
- tls_init now checks sk->sk_prot directly
This is somewhat safer then checking indirectly through sk->sk_family
Ilya Lesokhin (2):
net: Export tcpv6_prot
tls: Use correct sk->sk_prot for IPV6
net/ipv6/tcp_ipv6.c | 1 +
net/tls/Kconfig | 1 +
net/tls/tls_main.c | 50 ++++++++++++++++++++++++++++++++++++++------------
3 files changed, 40 insertions(+), 12 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH v3 net-next 1/2] net: Export tcpv6_prot
From: Ilya Lesokhin @ 2017-09-04 10:14 UTC (permalink / raw)
To: netdev, davem; +Cc: davejwatson, aviadye, Ilya Lesokhin, Boris Pismenny
In-Reply-To: <1504520041-55634-1-git-send-email-ilyal@mellanox.com>
Want to be able to use these in TLS.
Signed-off-by: Boris Pismenny <borisp@mellanox.com>
---
net/ipv6/tcp_ipv6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 38f76d8..60d0629 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1948,6 +1948,7 @@ struct proto tcpv6_prot = {
#endif
.diag_destroy = tcp_abort,
};
+EXPORT_SYMBOL_GPL(tcpv6_prot);
/* thinking of making this const? Don't.
* early_demux can change based on sysctl.
--
1.8.3.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox