* Re: [PATCH v2 net-next 0/4] cxgb4: Reference count MPS TCAM entries within a PF
From: David Miller @ 2019-06-24 14:54 UTC (permalink / raw)
To: rajur; +Cc: netdev, nirranjan, dt
In-Reply-To: <20190624.075323.2257534731180163594.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 24 Jun 2019 07:53:23 -0700 (PDT)
> You just changed it to a refcount_t and didn't try compiling the
> result?
You also need to fix this, which I tried to take care of this time:
Applying: cxgb4: Re-work the logic for mps refcounting
.git/rebase-apply/patch:291: new blank line at EOF.
+
^ permalink raw reply
* [PATCH RFC net-next 4/5] dt-bindings: net: dsa: mt7530: Add mediatek,ephy-handle to isolate ext. phy
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190624145251.4849-1-opensource@vdorst.com>
On some platforum the external phy can only interface to the port 5 of the
switch because the RGMII TX and RX lines are swapped. But it still can be
useful to use the internal phy of the switch to act as a WAN port which
connectes to the 2nd GMAC. This gives WAN port dedicated bandwidth to
the SOC. This increases the LAN and WAN routing.
By adding the optional property mediatek,ephy-handle, the external phy
is put in isolation mode when internal phy is connected to 2nd GMAC via
phy-handle property.
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
.../devicetree/bindings/net/dsa/mt7530.txt | 116 +++++++++++++++++-
1 file changed, 115 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
index f3486780f2c2..1e79fba5a774 100644
--- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
+++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
@@ -60,10 +60,20 @@ Depending on how the external PHY is wired:
2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
a ethernet port. But can't interface to the 2nd GMAC.
+Optional property:
+
+- mediatek,ephy-handle: Phandle of the external phy. In case you want to use
+ P0/4 as WAN port and have an external phy attached.
+ With this property the external phy is put in isolation
+ and powerdown mode in mode 2.
+
Based on the DT the port 5 mode is configured.
Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
-When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
+When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2 and when
+propertly "mediatek,ephy-handle" is valid it puts the externel phy in isolation
+mode.
+
phy-mode must be set, see also example 2 below!
* mt7621: phy-mode = "rgmii-txid";
* mt7623: phy-mode = "rgmii";
@@ -309,3 +319,107 @@ Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
};
};
};
+
+Example 4: MT7621: Port 4 is WAN port: 2nd GMAC -> P5 -> PHY P4
+ with an external phy.
+
+ð {
+ status = "okay";
+
+ gmac0: mac@0 {
+ compatible = "mediatek,eth-mac";
+ reg = <0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-mode = "rgmii-txid";
+ phy-handle = <&phy4>;
+ };
+
+ mdio: mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Internal phy 4 */
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+
+ /* external phy addr 0x07 */
+ ephy5: ethernet-phy@7 {
+ reg = <7>;
+ };
+
+ mt7530: switch@1f {
+ compatible = "mediatek,mt7621";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1f>;
+ pinctrl-names = "default";
+ mediatek,mcm;
+
+ /* Put this external phy in power-down and isolation
+ * when port 5 is used in PHY P0/P4 or DSA mode. Because
+ * external phy and port 5 share same bus to 2nd GMAC.
+ */
+ mediatek,ephy-handle = <&ephy5>;
+
+ resets = <&rstctrl 2>;
+ reset-names = "mcm";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+/* Commented out. Port 4 is handled by 2nd GMAC.
+ port@4 {
+ reg = <4>;
+ label = "lan4";
+ };
+*/
+
+ cpu_port0: port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
+};
--
2.20.1
^ permalink raw reply related
* [PATCH RFC net-next 5/5] net: dsa: mt7530: Add mediatek,ephy-handle to isolate external phy
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190624145251.4849-1-opensource@vdorst.com>
On some platforms the external phy can only interface with the port 5 of
the switch because the xMII TX and RX lines are swapped. But it still can
be useful to use the internal phy of the switch to act as a WAN port which
connectes to the 2nd GMAC. This gives the SOC a double the bandwidth
between LAN and WAN. Because LAN and WAN don't share the same interface
anymore.
By adding an optional property mediatek,ephy-handle, the external phy
is put in isolation mode when internal phy is linked with 2nd GMAC via
phy-handle property.
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/dsa/mt7530.c | 28 ++++++++++++++++++++++++++++
drivers/net/dsa/mt7530.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 838a921ca83e..25b0f35df75b 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -633,6 +633,26 @@ mt7530_get_sset_count(struct dsa_switch *ds, int port, int sset)
return ARRAY_SIZE(mt7530_mib);
}
+static int mt7530_isolate_ephy(struct dsa_switch *ds,
+ struct device_node *ephy_node)
+{
+ struct phy_device *phydev = of_phy_find_device(ephy_node);
+ int ret;
+
+ if (!phydev)
+ return 0;
+
+ ret = phy_modify(phydev, MII_BMCR, 0, (BMCR_ISOLATE | BMCR_PDOWN));
+ if (ret)
+ dev_err(ds->dev, "Failed to put phy %s in isolation mode!\n",
+ ephy_node->full_name);
+ else
+ dev_info(ds->dev, "Phy %s in isolation mode!\n",
+ ephy_node->full_name);
+
+ return ret;
+}
+
static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
{
struct mt7530_priv *priv = ds->priv;
@@ -655,6 +675,10 @@ static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
/* MT7530_P5_MODE_GPHY_P4: 2nd GMAC -> P5 -> P4 */
val &= ~MHWTRAP_P5_MAC_SEL & ~MHWTRAP_P5_DIS;
+ /* Isolate the external phy */
+ if (priv->ephy_node)
+ if (mt7530_isolate_ephy(ds, priv->ephy_node) < 0)
+ goto unlock_exit;
/* Setup the MAC by default for the cpu port */
mt7530_write(priv, MT7530_PMCR_P(5), 0x56300);
break;
@@ -1330,6 +1354,10 @@ mt7530_setup(struct dsa_switch *ds)
mt7530_port_disable(ds, i);
}
+ /* Get external phy phandle */
+ priv->ephy_node = of_parse_phandle(priv->dev->of_node,
+ "mediatek,ephy-handle", 0);
+
/* Setup port 5 */
priv->p5_mode = P5_MODE_DISABLED;
interface = PHY_INTERFACE_MODE_NA;
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index f2a84ef48548..eb079e81a8e8 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -459,6 +459,7 @@ static const char *p5_modes(unsigned int p5_mode)
* @reg_mutex: The lock for protecting among process accessing
* registers
* @p5_mode: PORT 5 mode status
+ * @ephy_node: External phy of_node.
*/
struct mt7530_priv {
struct device *dev;
@@ -472,6 +473,7 @@ struct mt7530_priv {
unsigned int id;
bool mcm;
unsigned int p5_mode;
+ struct device_node *ephy_node;
struct mt7530_port ports[MT7530_NUM_PORTS];
/* protect among processes for registers access*/
--
2.20.1
^ permalink raw reply related
* [PATCH RFC net-next 3/5] net: dsa: mt7530: Add support for port 5
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190624145251.4849-1-opensource@vdorst.com>
Adding support for port 5.
Port 5 ca muxed/interface to:
- internal 5th GMAC of the switch; can be used as 2nd CPU port or as
extra port with an external phy for a 6th ethernet port.
- internal PHY of port 0 or 4; Used in most applications so that port 0
or 4 is the WAN port and interfaces with the 2nd GMAC of the SOC.
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/dsa/mt7530.c | 135 +++++++++++++++++++++++++++++++++++++--
drivers/net/dsa/mt7530.h | 28 ++++++++
2 files changed, 159 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 9c5e4dd00826..838a921ca83e 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -633,6 +633,74 @@ mt7530_get_sset_count(struct dsa_switch *ds, int port, int sset)
return ARRAY_SIZE(mt7530_mib);
}
+static void mt7530_setup_port5(struct dsa_switch *ds, phy_interface_t interface)
+{
+ struct mt7530_priv *priv = ds->priv;
+ u8 tx_delay = 0;
+ int val;
+
+ mutex_lock(&priv->reg_mutex);
+
+ val = mt7530_read(priv, MT7530_MHWTRAP);
+
+ val |= MHWTRAP_MANUAL | MHWTRAP_P5_MAC_SEL | MHWTRAP_P5_DIS;
+ val &= ~MHWTRAP_P5_RGMII_MODE & ~MHWTRAP_PHY0_SEL;
+
+ switch (priv->p5_mode) {
+ case P5_MODE_GPHY_P0:
+ /* MT7530_P5_MODE_GPHY_P0: 2nd GMAC -> P5 -> P0 */
+ val |= MHWTRAP_PHY0_SEL;
+ /* fall through */
+ case P5_MODE_GPHY_P4:
+ /* MT7530_P5_MODE_GPHY_P4: 2nd GMAC -> P5 -> P4 */
+ val &= ~MHWTRAP_P5_MAC_SEL & ~MHWTRAP_P5_DIS;
+
+ /* Setup the MAC by default for the cpu port */
+ mt7530_write(priv, MT7530_PMCR_P(5), 0x56300);
+ break;
+ case P5_MODE_GMAC:
+ /* MT7530_P5_MODE_GMAC: P5 -> External phy or 2nd GMAC */
+ val &= ~MHWTRAP_P5_DIS;
+ break;
+ case P5_MODE_DISABLED:
+ interface = PHY_INTERFACE_MODE_NA;
+ break;
+ default:
+ dev_err(ds->dev, "Unsupported p5_mode %d\n", priv->p5_mode);
+ goto unlock_exit;
+ }
+
+ /* Setup RGMII settings */
+ if (phy_interface_mode_is_rgmii(interface)) {
+ val |= MHWTRAP_P5_RGMII_MODE;
+
+ /* P5 RGMII RX Clock Control: delay setting for 1000M */
+ mt7530_write(priv, MT7530_P5RGMIIRXCR, CSR_RGMII_EDGE_ALIGN);
+
+ /* Don't set delay in DSA mode */
+ if (!dsa_is_dsa_port(priv->ds, 5) &&
+ (interface == PHY_INTERFACE_MODE_RGMII_TXID ||
+ interface == PHY_INTERFACE_MODE_RGMII_ID))
+ tx_delay = 4; /* n * 0.5 ns */
+
+ /* P5 RGMII TX Clock Control: delay x */
+ mt7530_write(priv, MT7530_P5RGMIITXCR,
+ CSR_RGMII_TXC_CFG(0x10 + tx_delay));
+
+ /* reduce P5 RGMII Tx driving, 8mA */
+ mt7530_write(priv, MT7530_IO_DRV_CR,
+ P5_IO_CLK_DRV(1) | P5_IO_DATA_DRV(1));
+ }
+
+ mt7530_write(priv, MT7530_MHWTRAP, val);
+
+ dev_info(ds->dev, "Setup P5, HWTRAP=0x%x, port-mode=%s, phy-mode=%s\n",
+ val, p5_modes(priv->p5_mode), phy_modes(interface));
+
+unlock_exit:
+ mutex_unlock(&priv->reg_mutex);
+}
+
static int
mt7530_cpu_port_enable(struct mt7530_priv *priv,
int port)
@@ -1173,6 +1241,10 @@ mt7530_setup(struct dsa_switch *ds)
u32 id, val;
struct device_node *dn;
struct mt7530_dummy_poll p;
+ phy_interface_t interface;
+ struct device_node *mac_np;
+ struct device_node *phy_node;
+ const __be32 *_id;
/* The parent node of master netdev which holds the common system
* controller also is the container for two GMACs nodes representing
@@ -1258,6 +1330,40 @@ mt7530_setup(struct dsa_switch *ds)
mt7530_port_disable(ds, i);
}
+ /* Setup port 5 */
+ priv->p5_mode = P5_MODE_DISABLED;
+ interface = PHY_INTERFACE_MODE_NA;
+
+ if (!dsa_is_unused_port(ds, 5)) {
+ priv->p5_mode = P5_MODE_GMAC;
+ interface = of_get_phy_mode(ds->ports[5].dn);
+ } else {
+ /* Scan the ethernet nodes. Look for GMAC1, Lookup used phy */
+ for_each_child_of_node(dn, mac_np) {
+ if (!of_device_is_compatible(mac_np,
+ "mediatek,eth-mac"))
+ continue;
+ _id = of_get_property(mac_np, "reg", NULL);
+ if (be32_to_cpup(_id) != 1)
+ continue;
+
+ interface = of_get_phy_mode(mac_np);
+ phy_node = of_parse_phandle(mac_np, "phy-handle", 0);
+
+ if (phy_node->parent == priv->dev->of_node->parent) {
+ _id = of_get_property(phy_node, "reg", NULL);
+ id = be32_to_cpup(_id);
+ if (id == 0)
+ priv->p5_mode = P5_MODE_GPHY_P0;
+ if (id == 4)
+ priv->p5_mode = P5_MODE_GPHY_P4;
+ }
+ break;
+ }
+ }
+
+ mt7530_setup_port5(ds, interface);
+
/* Flush the FDB table */
ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, NULL);
if (ret < 0)
@@ -1283,7 +1389,20 @@ static void mt7530_phylink_mac_config(struct dsa_switch *ds, int port,
if (state->interface != PHY_INTERFACE_MODE_GMII)
goto unsupported;
break;
- /* case 5: Port 5 is not supported! */
+ case 5: /* 2nd cpu port with phy of port 0 or 4 / external phy */
+ if (!phy_interface_mode_is_rgmii(state->interface) &&
+ state->interface != PHY_INTERFACE_MODE_MII)
+ goto unsupported;
+ if (priv->p5_mode != P5_MODE_GMAC) {
+ priv->p5_mode = P5_MODE_GMAC;
+ mt7530_port_disable(ds, port);
+ mt7530_setup_port5(ds, state->interface);
+ mt7530_port_enable(ds, port, NULL);
+ }
+ /* We are connected to external phy */
+ if (dsa_is_user_port(ds, 5))
+ mcr |= PMCR_EXT_PHY;
+ break;
case 6: /* 1st cpu port */
if (state->interface != PHY_INTERFACE_MODE_RGMII &&
state->interface != PHY_INTERFACE_MODE_TRGMII)
@@ -1364,7 +1483,12 @@ static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
state->interface != PHY_INTERFACE_MODE_GMII)
goto unsupported;
break;
- /* case 5: Port 5 not supported! */
+ case 5: /* 2nd cpu port with phy of port 0 or 4 / external phy */
+ if (!phy_interface_mode_is_rgmii(state->interface) &&
+ state->interface != PHY_INTERFACE_MODE_MII &&
+ state->interface != PHY_INTERFACE_MODE_NA)
+ goto unsupported;
+ break;
case 6: /* 1st cpu port */
if (state->interface != PHY_INTERFACE_MODE_RGMII &&
state->interface != PHY_INTERFACE_MODE_TRGMII)
@@ -1385,8 +1509,11 @@ static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
phylink_set(mask, 10baseT_Full);
phylink_set(mask, 100baseT_Half);
phylink_set(mask, 100baseT_Full);
- phylink_set(mask, 1000baseT_Full);
- phylink_set(mask, 1000baseT_Half);
+
+ if (state->interface != PHY_INTERFACE_MODE_MII) {
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseT_Half);
+ }
linkmode_and(supported, supported, mask);
linkmode_and(state->advertising, state->advertising, mask);
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 41d9a132ac70..f2a84ef48548 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -186,6 +186,7 @@ enum mt7530_vlan_port_attr {
/* Register for port MAC control register */
#define MT7530_PMCR_P(x) (0x3000 + ((x) * 0x100))
#define PMCR_IFG_XMIT(x) (((x) & 0x3) << 18)
+#define PMCR_EXT_PHY BIT(17)
#define PMCR_MAC_MODE BIT(16)
#define PMCR_FORCE_MODE BIT(15)
#define PMCR_TX_EN BIT(14)
@@ -260,6 +261,7 @@ enum mt7530_vlan_port_attr {
/* Register for hw trap modification */
#define MT7530_MHWTRAP 0x7804
+#define MHWTRAP_PHY0_SEL BIT(20)
#define MHWTRAP_MANUAL BIT(16)
#define MHWTRAP_P5_MAC_SEL BIT(13)
#define MHWTRAP_P6_DIS BIT(8)
@@ -417,6 +419,30 @@ struct mt7530_port {
u16 pvid;
};
+/* Port 5 Mode definitions */
+enum p5_mode {
+ P5_MODE_DISABLED = 0,
+ P5_MODE_GPHY_P0,
+ P5_MODE_GPHY_P4,
+ P5_MODE_GMAC,
+};
+
+static const char *p5_modes(unsigned int p5_mode)
+{
+ switch (p5_mode) {
+ case P5_MODE_DISABLED:
+ return "DISABLED";
+ case P5_MODE_GPHY_P0:
+ return "PHY P0";
+ case P5_MODE_GPHY_P4:
+ return "PHY P4";
+ case P5_MODE_GMAC:
+ return "GMAC";
+ default:
+ return "unknown";
+ }
+}
+
/* struct mt7530_priv - This is the main data structure for holding the state
* of the driver
* @dev: The device pointer
@@ -432,6 +458,7 @@ struct mt7530_port {
* @ports: Holding the state among ports
* @reg_mutex: The lock for protecting among process accessing
* registers
+ * @p5_mode: PORT 5 mode status
*/
struct mt7530_priv {
struct device *dev;
@@ -444,6 +471,7 @@ struct mt7530_priv {
struct gpio_desc *reset;
unsigned int id;
bool mcm;
+ unsigned int p5_mode;
struct mt7530_port ports[MT7530_NUM_PORTS];
/* protect among processes for registers access*/
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 0/4] cxgb4: Reference count MPS TCAM entries within a PF
From: David Miller @ 2019-06-24 14:53 UTC (permalink / raw)
To: rajur; +Cc: netdev, nirranjan, dt
In-Reply-To: <20190624.075132.2137301224911651949.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 24 Jun 2019 07:51:32 -0700 (PDT)
> From: Raju Rangoju <rajur@chelsio.com>
> Date: Mon, 24 Jun 2019 14:20:33 +0530
>
>> Firmware reference counts the MPS TCAM entries by PF and VF,
>> but it does not do it for usage within a PF or VF. This patch
>> adds the support to track MPS TCAM entries within a PF.
>>
>> v1->v2:
>> Use refcount_t type instead of atomic_t for mps reference count
>
> Series applied, thanks.
Umm, REALLY?!?!?!
drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c: In function ‘cxgb4_mps_ref_dec_by_mac’:
drivers/net/ethernet/chelsio/cxgb4/cxgb4_mps.c:17:29: error: passing argument 1 of ‘atomic_dec_and_test’ from incompatible pointer type [-Werror=incompatible-pointer-types]
if (!atomic_dec_and_test(&mps_entry->refcnt)) {
^~~~~~~~~~~~~~~~~~
You just changed it to a refcount_t and didn't try compiling the
result?
The whole point of refcount_t is that it uses a different set of
interfaces to manipulate the object and you have to therefore
update all the call sites properly.
Reverted...
^ permalink raw reply
* [PATCH RFC net-next 2/5] dt-bindings: net: dsa: mt7530: Add support for port 5
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst,
devicetree
In-Reply-To: <20190624145251.4849-1-opensource@vdorst.com>
MT7530 port 5 has many modes/configurations.
Update the documentation how to use port 5.
Signed-off-by: René van Dorst <opensource@vdorst.com>
CC: devicetree@vger.kernel.org
---
.../devicetree/bindings/net/dsa/mt7530.txt | 215 ++++++++++++++++++
1 file changed, 215 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
index 47aa205ee0bd..f3486780f2c2 100644
--- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt
+++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt
@@ -35,6 +35,39 @@ Required properties for the child nodes within ports container:
- phy-mode: String, must be either "trgmii" or "rgmii" for port labeled
"cpu".
+Port 5 of the switch is muxed between:
+1. GMAC5: GMAC5 can interface with another external MAC or PHY.
+2. PHY of port 0 or port 4: PHY interfaces with an external MAC like 2nd GMAC
+ of the SOC. Used in many setups where port 0/4 becomes the WAN port.
+
+Port 5 modes/configurations:
+1. Port 5 is disabled and isolated: An external phy can interface to the 2nd
+ GMAC of the SOC.
+ In the case of a build-in MT7530 switch, port 5 shares the RGMII bus with 2nd
+ GMAC and an optional external phy. Mind the GPIO/pinctl settings of the SOC!
+2. Port 5 is muxed to PHY of port 0/4: Port 0/4 interfaces with 2nd GMAC.
+ It is a simple MAC to PHY interface, port 5 needs to be setup for xMII mode
+ and RGMII delay.
+3. Port 5 is muxed to GMAC5 and can interface to an external phy.
+ Port 5 becomes an extra switch port.
+ Only works on platform where external phy TX<->RX lines are swapped.
+ Like in the Ubiquiti ER-X-SFP.
+4. Port 5 is muxed to GMAC5 and interfaces with the 2nd GAMC as 2nd CPU port.
+ Currently a 2nd CPU port is not supported by DSA code.
+
+Depending on how the external PHY is wired:
+1. normal: The PHY can only connect to 2nd GMAC but not to the switch
+2. swapped: RGMII TX, RX are swapped; external phy interface with the switch as
+ a ethernet port. But can't interface to the 2nd GMAC.
+
+Based on the DT the port 5 mode is configured.
+
+Driver tries to lookup the phy-handle of the 2nd GMAC of the master device.
+When phy-handle matches PHY of port 0 or 4 then port 5 set-up as mode 2.
+phy-mode must be set, see also example 2 below!
+ * mt7621: phy-mode = "rgmii-txid";
+ * mt7623: phy-mode = "rgmii";
+
See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional
required, optional properties and how the integrated switch subnodes must
be specified.
@@ -94,3 +127,185 @@ Example:
};
};
};
+
+Example 2: MT7621: Port 4 is WAN port: 2nd GMAC -> Port 5 -> PHY port 4.
+
+ð {
+ status = "okay";
+
+ gmac0: mac@0 {
+ compatible = "mediatek,eth-mac";
+ reg = <0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+
+ gmac1: mac@1 {
+ compatible = "mediatek,eth-mac";
+ reg = <1>;
+ phy-mode = "rgmii-txid";
+ phy-handle = <&phy4>;
+ };
+
+ mdio: mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Internal phy */
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+
+ mt7530: switch@1f {
+ compatible = "mediatek,mt7621";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1f>;
+ pinctrl-names = "default";
+ mediatek,mcm;
+
+ resets = <&rstctrl 2>;
+ reset-names = "mcm";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+/* Commented out. Port 4 is handled by 2nd GMAC.
+ port@4 {
+ reg = <4>;
+ label = "lan4";
+ };
+*/
+
+ cpu_port0: port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
+};
+
+Example 3: MT7621: Port 5 is connected to external PHY: Port 5 -> external PHY.
+
+ð {
+ status = "okay";
+
+ gmac0: mac@0 {
+ compatible = "mediatek,eth-mac";
+ reg = <0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+
+ mdio: mdio-bus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* External phy */
+ ephy5: ethernet-phy@7 {
+ reg = <7>;
+ };
+
+ mt7530: switch@1f {
+ compatible = "mediatek,mt7621";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1f>;
+ pinctrl-names = "default";
+ mediatek,mcm;
+
+ resets = <&rstctrl 2>;
+ reset-names = "mcm";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan0";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan3";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan4";
+ };
+
+ port@5 {
+ reg = <5>;
+ label = "lan5";
+ phy-mode = "rgmii";
+ phy-handle = <&ephy5>;
+ };
+
+ cpu_port0: port@6 {
+ reg = <6>;
+ label = "cpu";
+ ethernet = <&gmac0>;
+ phy-mode = "rgmii";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
+ };
+ };
+};
--
2.20.1
^ permalink raw reply related
* [PATCH RFC net-next 1/5] net: dsa: mt7530: Convert to PHYLINK API
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst
In-Reply-To: <20190624145251.4849-1-opensource@vdorst.com>
Convert mt7530 to PHYLINK API
Signed-off-by: René van Dorst <opensource@vdorst.com>
---
drivers/net/dsa/mt7530.c | 237 +++++++++++++++++++++++++++++----------
drivers/net/dsa/mt7530.h | 9 ++
2 files changed, 187 insertions(+), 59 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index 3181e95586d6..9c5e4dd00826 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -13,7 +13,7 @@
#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include <linux/of_platform.h>
-#include <linux/phy.h>
+#include <linux/phylink.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
@@ -633,63 +633,6 @@ mt7530_get_sset_count(struct dsa_switch *ds, int port, int sset)
return ARRAY_SIZE(mt7530_mib);
}
-static void mt7530_adjust_link(struct dsa_switch *ds, int port,
- struct phy_device *phydev)
-{
- struct mt7530_priv *priv = ds->priv;
-
- if (phy_is_pseudo_fixed_link(phydev)) {
- dev_dbg(priv->dev, "phy-mode for master device = %x\n",
- phydev->interface);
-
- /* Setup TX circuit incluing relevant PAD and driving */
- mt7530_pad_clk_setup(ds, phydev->interface);
-
- if (priv->id == ID_MT7530) {
- /* Setup RX circuit, relevant PAD and driving on the
- * host which must be placed after the setup on the
- * device side is all finished.
- */
- mt7623_pad_clk_setup(ds);
- }
- } else {
- u16 lcl_adv = 0, rmt_adv = 0;
- u8 flowctrl;
- u32 mcr = PMCR_USERP_LINK | PMCR_FORCE_MODE;
-
- switch (phydev->speed) {
- case SPEED_1000:
- mcr |= PMCR_FORCE_SPEED_1000;
- break;
- case SPEED_100:
- mcr |= PMCR_FORCE_SPEED_100;
- break;
- }
-
- if (phydev->link)
- mcr |= PMCR_FORCE_LNK;
-
- if (phydev->duplex) {
- mcr |= PMCR_FORCE_FDX;
-
- if (phydev->pause)
- rmt_adv = LPA_PAUSE_CAP;
- if (phydev->asym_pause)
- rmt_adv |= LPA_PAUSE_ASYM;
-
- lcl_adv = linkmode_adv_to_lcl_adv_t(
- phydev->advertising);
- flowctrl = mii_resolve_flowctrl_fdx(lcl_adv, rmt_adv);
-
- if (flowctrl & FLOW_CTRL_TX)
- mcr |= PMCR_TX_FC_EN;
- if (flowctrl & FLOW_CTRL_RX)
- mcr |= PMCR_RX_FC_EN;
- }
- mt7530_write(priv, MT7530_PMCR_P(port), mcr);
- }
-}
-
static int
mt7530_cpu_port_enable(struct mt7530_priv *priv,
int port)
@@ -1323,6 +1266,178 @@ mt7530_setup(struct dsa_switch *ds)
return 0;
}
+static void mt7530_phylink_mac_config(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ const struct phylink_link_state *state)
+{
+ struct mt7530_priv *priv = ds->priv;
+ u32 mcr = PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | PMCR_BACKOFF_EN |
+ PMCR_BACKPR_EN | PMCR_TX_EN | PMCR_RX_EN;
+
+ switch (port) {
+ case 0: /* Internal phy */
+ case 1:
+ case 2:
+ case 3:
+ case 4:
+ if (state->interface != PHY_INTERFACE_MODE_GMII)
+ goto unsupported;
+ break;
+ /* case 5: Port 5 is not supported! */
+ case 6: /* 1st cpu port */
+ if (state->interface != PHY_INTERFACE_MODE_RGMII &&
+ state->interface != PHY_INTERFACE_MODE_TRGMII)
+ goto unsupported;
+
+ /* Setup TX circuit incluing relevant PAD and driving */
+ mt7530_pad_clk_setup(ds, state->interface);
+
+ if (priv->id == ID_MT7530) {
+ /* Setup RX circuit, relevant PAD and driving on the
+ * host which must be placed after the setup on the
+ * device side is all finished.
+ */
+ mt7623_pad_clk_setup(ds);
+ }
+ break;
+ default:
+ dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
+ return;
+ }
+
+ if (!state->an_enabled || mode == MLO_AN_FIXED) {
+ mcr |= PMCR_FORCE_MODE;
+
+ if (state->speed == SPEED_1000)
+ mcr |= PMCR_FORCE_SPEED_1000;
+ if (state->speed == SPEED_100)
+ mcr |= PMCR_FORCE_SPEED_100;
+ if (state->duplex == DUPLEX_FULL)
+ mcr |= PMCR_FORCE_FDX;
+ if (state->link || mode == MLO_AN_FIXED)
+ mcr |= PMCR_FORCE_LNK;
+ if (state->pause || phylink_test(state->advertising, Pause))
+ mcr |= PMCR_TX_FC_EN | PMCR_RX_FC_EN;
+ if (state->pause & MLO_PAUSE_TX)
+ mcr |= PMCR_TX_FC_EN;
+ if (state->pause & MLO_PAUSE_RX)
+ mcr |= PMCR_RX_FC_EN;
+ }
+
+ mt7530_write(priv, MT7530_PMCR_P(port), mcr);
+
+ return;
+
+unsupported:
+ dev_err(ds->dev, "%s: P%d: Unsupported phy_interface mode: %d (%s)\n",
+ __func__, port, state->interface, phy_modes(state->interface));
+}
+
+static void mt7530_phylink_mac_link_down(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ phy_interface_t interface)
+{
+ /* Do nothing */
+}
+
+static void mt7530_phylink_mac_link_up(struct dsa_switch *ds, int port,
+ unsigned int mode,
+ phy_interface_t interface,
+ struct phy_device *phydev)
+{
+ /* Do nothing */
+}
+
+static void mt7530_phylink_validate(struct dsa_switch *ds, int port,
+ unsigned long *supported,
+ struct phylink_link_state *state)
+{
+ __ETHTOOL_DECLARE_LINK_MODE_MASK(mask) = { 0, };
+
+ switch (port) {
+ case 0: /* Internal phy */
+ case 1:
+ case 2:
+ case 3:
+ case 4:
+ if (state->interface != PHY_INTERFACE_MODE_NA &&
+ state->interface != PHY_INTERFACE_MODE_GMII)
+ goto unsupported;
+ break;
+ /* case 5: Port 5 not supported! */
+ case 6: /* 1st cpu port */
+ if (state->interface != PHY_INTERFACE_MODE_RGMII &&
+ state->interface != PHY_INTERFACE_MODE_TRGMII)
+ goto unsupported;
+ break;
+ default:
+ linkmode_zero(supported);
+ dev_err(ds->dev, "%s: unsupported port: %i\n", __func__, port);
+ return;
+ }
+
+ phylink_set(mask, Autoneg);
+ phylink_set(mask, Pause);
+ phylink_set(mask, Asym_Pause);
+ phylink_set(mask, MII);
+
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseT_Half);
+
+ linkmode_and(supported, supported, mask);
+ linkmode_and(state->advertising, state->advertising, mask);
+ return;
+
+unsupported:
+ linkmode_zero(supported);
+ dev_err(ds->dev, "%s: unsupported interface mode: [0x%x] %s\n",
+ __func__, state->interface, phy_modes(state->interface));
+}
+
+static int
+mt7530_phylink_mac_link_state(struct dsa_switch *ds, int port,
+ struct phylink_link_state *state)
+{
+ struct mt7530_priv *priv = ds->priv;
+ u32 pmsr;
+
+ if (port < 0 || port >= MT7530_NUM_PORTS)
+ return -EINVAL;
+
+ pmsr = mt7530_read(priv, MT7530_PMSR_P(port));
+
+ state->link = (pmsr & PMSR_LINK);
+ state->an_complete = state->link;
+ state->duplex = (pmsr & PMSR_DPX) >> 1;
+
+ switch (pmsr & (PMSR_SPEED_1000 | PMSR_SPEED_100)) {
+ case 0:
+ state->speed = SPEED_10;
+ break;
+ case PMSR_SPEED_100:
+ state->speed = SPEED_100;
+ break;
+ case PMSR_SPEED_1000:
+ state->speed = SPEED_1000;
+ break;
+ default:
+ state->speed = SPEED_UNKNOWN;
+ break;
+ }
+
+ state->pause = 0;
+ if (pmsr & PMSR_RX_FC)
+ state->pause |= MLO_PAUSE_RX;
+ if (pmsr & PMSR_TX_FC)
+ state->pause |= MLO_PAUSE_TX;
+
+ return 1;
+}
+
static const struct dsa_switch_ops mt7530_switch_ops = {
.get_tag_protocol = mtk_get_tag_protocol,
.setup = mt7530_setup,
@@ -1331,7 +1446,6 @@ static const struct dsa_switch_ops mt7530_switch_ops = {
.phy_write = mt7530_phy_write,
.get_ethtool_stats = mt7530_get_ethtool_stats,
.get_sset_count = mt7530_get_sset_count,
- .adjust_link = mt7530_adjust_link,
.port_enable = mt7530_port_enable,
.port_disable = mt7530_port_disable,
.port_stp_state_set = mt7530_stp_state_set,
@@ -1344,6 +1458,11 @@ static const struct dsa_switch_ops mt7530_switch_ops = {
.port_vlan_prepare = mt7530_port_vlan_prepare,
.port_vlan_add = mt7530_port_vlan_add,
.port_vlan_del = mt7530_port_vlan_del,
+ .phylink_validate = mt7530_phylink_validate,
+ .phylink_mac_link_state = mt7530_phylink_mac_link_state,
+ .phylink_mac_config = mt7530_phylink_mac_config,
+ .phylink_mac_link_down = mt7530_phylink_mac_link_down,
+ .phylink_mac_link_up = mt7530_phylink_mac_link_up,
};
static const struct of_device_id mt7530_of_match[] = {
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index bfac90f48102..41d9a132ac70 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -198,6 +198,7 @@ enum mt7530_vlan_port_attr {
#define PMCR_FORCE_SPEED_100 BIT(2)
#define PMCR_FORCE_FDX BIT(1)
#define PMCR_FORCE_LNK BIT(0)
+#define PMCR_FORCE_LNK_DOWN PMCR_FORCE_MODE
#define PMCR_COMMON_LINK (PMCR_IFG_XMIT(1) | PMCR_MAC_MODE | \
PMCR_BACKOFF_EN | PMCR_BACKPR_EN | \
PMCR_TX_EN | PMCR_RX_EN | \
@@ -218,6 +219,14 @@ enum mt7530_vlan_port_attr {
PMCR_TX_FC_EN | PMCR_RX_FC_EN)
#define MT7530_PMSR_P(x) (0x3008 + (x) * 0x100)
+#define PMSR_EEE1G BIT(7)
+#define PMSR_EEE100M BIT(6)
+#define PMSR_RX_FC BIT(5)
+#define PMSR_TX_FC BIT(4)
+#define PMSR_SPEED_1000 BIT(3)
+#define PMSR_SPEED_100 BIT(2)
+#define PMSR_DPX BIT(1)
+#define PMSR_LINK BIT(0)
/* Register for MIB */
#define MT7530_PORT_MIB_COUNTER(x) (0x4000 + (x) * 0x100)
--
2.20.1
^ permalink raw reply related
* [PATCH RFC net-next 0/5] net: dsa: MT7530: Convert to PHYLINK and add support for port 5
From: René van Dorst @ 2019-06-24 14:52 UTC (permalink / raw)
To: sean.wang, f.fainelli, linux, davem, matthias.bgg, andrew,
vivien.didelot
Cc: frank-w, netdev, linux-mediatek, linux-mips, René van Dorst
Here by I am sending my current patches for review.
I want to know if I am on the right track.
1. 0001-net-dsa-mt7530-Convert-to-PHYLINK-API.patch
This patch converts mt7530 to PHYLINK API.
2. 0002-dt-bindings-net-dsa-mt7530-Add-support-for-port-5.patch
3. 0003-net-dsa-mt7530-Add-support-for-port-5.patch
These 2 patches adding support for port 5 of the switch.
Optional:
4. 0004-dt-bindings-net-dsa-mt7530-Add-mediatek-ephy-handle-.patch
5. 0005-net-dsa-mt7530-Add-mediatek-ephy-handle-to-isolate-e.patch
These 2 patches adding property "mediatek,ephy-handle".
When set, it puts the external phy in isolation mode.
This allows the switch PHY of port 0/4 to interface with 2nd GMAC of
the SOC. The external phy, 2nd GMAC and switch port 5 shares the same
MII bus.
FWIW: Also working on converting the mediatek ethernet driver to PHYLINK.
This need a bit more work duo to the SGMII work and support hardware which
I don't have.
https://github.com/vDorst/linux-1/commit/54004b807cba0dcec1653c1c290c2e5aae5127c2
René van Dorst (5):
net: dsa: mt7530: Convert to PHYLINK API
dt-bindings: net: dsa: mt7530: Add support for port 5
net: dsa: mt7530: Add support for port 5
dt-bindings: net: dsa: mt7530: Add mediatek,ephy-handle to isolate
ext. phy
net: dsa: mt7530: Add mediatek,ephy-handle to isolate external phy
.../devicetree/bindings/net/dsa/mt7530.txt | 329 ++++++++++++++++
drivers/net/dsa/mt7530.c | 366 +++++++++++++++---
drivers/net/dsa/mt7530.h | 39 ++
3 files changed, 688 insertions(+), 46 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] cxgb4: Reference count MPS TCAM entries within a PF
From: David Miller @ 2019-06-24 14:51 UTC (permalink / raw)
To: rajur; +Cc: netdev, nirranjan, dt
In-Reply-To: <20190624085037.2358-1-rajur@chelsio.com>
From: Raju Rangoju <rajur@chelsio.com>
Date: Mon, 24 Jun 2019 14:20:33 +0530
> Firmware reference counts the MPS TCAM entries by PF and VF,
> but it does not do it for usage within a PF or VF. This patch
> adds the support to track MPS TCAM entries within a PF.
>
> v1->v2:
> Use refcount_t type instead of atomic_t for mps reference count
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH bpf-next v5 00/16] AF_XDP infrastructure improvements and mlx5e support
From: Daniel Borkmann @ 2019-06-24 14:48 UTC (permalink / raw)
To: Björn Töpel, Maxim Mikityanskiy
Cc: Alexei Starovoitov, Björn Töpel, Magnus Karlsson,
bpf@vger.kernel.org, netdev@vger.kernel.org, David S. Miller,
Saeed Mahameed, Jonathan Lemon, Tariq Toukan, Martin KaFai Lau,
Song Liu, Yonghong Song, Jakub Kicinski, Maciej Fijalkowski
In-Reply-To: <CAJ+HfNia-vUv7Eumfs8aMYGGkxPbbUQ++F+BQ=9C1NtP0Jt3hA@mail.gmail.com>
On 06/20/2019 11:13 AM, Björn Töpel wrote:
> On Tue, 18 Jun 2019 at 14:00, Maxim Mikityanskiy <maximmi@mellanox.com> wrote:
>>
>> This series contains improvements to the AF_XDP kernel infrastructure
>> and AF_XDP support in mlx5e. The infrastructure improvements are
>> required for mlx5e, but also some of them benefit to all drivers, and
>> some can be useful for other drivers that want to implement AF_XDP.
>>
>> The performance testing was performed on a machine with the following
>> configuration:
>>
>> - 24 cores of Intel Xeon E5-2620 v3 @ 2.40 GHz
>> - Mellanox ConnectX-5 Ex with 100 Gbit/s link
>>
>> The results with retpoline disabled, single stream:
>>
>> txonly: 33.3 Mpps (21.5 Mpps with queue and app pinned to the same CPU)
>> rxdrop: 12.2 Mpps
>> l2fwd: 9.4 Mpps
>>
>> The results with retpoline enabled, single stream:
>>
>> txonly: 21.3 Mpps (14.1 Mpps with queue and app pinned to the same CPU)
>> rxdrop: 9.9 Mpps
>> l2fwd: 6.8 Mpps
>>
>> v2 changes:
>>
>> Added patches for mlx5e and addressed the comments for v1. Rebased for
>> bpf-next.
>>
>> v3 changes:
>>
>> Rebased for the newer bpf-next, resolved conflicts in libbpf. Addressed
>> Björn's comments for coding style. Fixed a bug in error handling flow in
>> mlx5e_open_xsk.
>>
>> v4 changes:
>>
>> UAPI is not changed, XSK RX queues are exposed to the kernel. The lower
>> half of the available amount of RX queues are regular queues, and the
>> upper half are XSK RX queues. The patch "xsk: Extend channels to support
>> combined XSK/non-XSK traffic" was dropped. The final patch was reworked
>> accordingly.
>>
>> Added "net/mlx5e: Attach/detach XDP program safely", as the changes
>> introduced in the XSK patch base on the stuff from this one.
>>
>> Added "libbpf: Support drivers with non-combined channels", which aligns
>> the condition in libbpf with the condition in the kernel.
>>
>> Rebased over the newer bpf-next.
>>
>> v5 changes:
>>
>> In v4, ethtool reports the number of channels as 'combined' and the
>> number of XSK RX queues as 'rx' for mlx5e. It was changed, so that 'rx'
>> is 0, and 'combined' reports the double amount of channels if there is
>> an active UMEM - to make libbpf happy.
>>
>> The patch for libbpf was dropped. Although it's still useful and fixes
>> things, it raises some disagreement, so I'm dropping it - it's no longer
>> useful for mlx5e anymore after the change above.
>
> Just a heads-up: There are some checkpatch warnings (>80 chars/line)
> for the mlnx5 driver parts, and the series didn't apply cleanly on
> bpf-next for me.
>
> I haven't been able to test the mlnx5 parts.
>
> Parts of the series are unrelated/orthogonal, and could be submitted
> as separate series, e.g. patches {1,7} and patches {3,4}. No blockers
> for me, though.
>
> Thanks for the hard work!
+1
> For the series:
> Acked-by: Björn Töpel <bjorn.topel@intel.com>
Looks good to me, but as Björn already indicated, there's one last rebase
needed since it doesn't apply cleanly in the last one that adds the actual
AF_XDP support, please take a look and rebase:
[...]
Applying: net/mlx5e: Attach/detach XDP program safely
Applying: xsk: Add API to check for available entries in FQ
Applying: xsk: Add getsockopt XDP_OPTIONS
Applying: libbpf: Support getsockopt XDP_OPTIONS
Applying: xsk: Change the default frame size to 4096 and allow controlling it
Applying: xsk: Return the whole xdp_desc from xsk_umem_consume_tx
Using index info to reconstruct a base tree...
M drivers/net/ethernet/intel/i40e/i40e_xsk.c
M drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
Auto-merging drivers/net/ethernet/intel/i40e/i40e_xsk.c
Applying: net/mlx5e: Replace deprecated PCI_DMA_TODEVICE
Applying: net/mlx5e: Calculate linear RX frag size considering XSK
Applying: net/mlx5e: Allow ICO SQ to be used by multiple RQs
Applying: net/mlx5e: Refactor struct mlx5e_xdp_info
Applying: net/mlx5e: Share the XDP SQ for XDP_TX between RQs
Applying: net/mlx5e: XDP_TX from UMEM support
Applying: net/mlx5e: Consider XSK in XDP MTU limit calculation
Applying: net/mlx5e: Encapsulate open/close queues into a function
Applying: net/mlx5e: Move queue param structs to en/params.h
Applying: net/mlx5e: Add XSK zero-copy support
fatal: sha1 information is lacking or useless (drivers/net/ethernet/mellanox/mlx5/core/en.h).
error: could not build fake ancestor
Patch failed at 0016 net/mlx5e: Add XSK zero-copy support
Thanks,
Daniel
^ permalink raw reply
* [PATCH][next] 6lowpan: fix off-by-one comparison of index id with LOWPAN_IPHC_CTX_TABLE_SIZE
From: Colin King @ 2019-06-24 14:47 UTC (permalink / raw)
To: Alexander Aring, Jukka Rissanen, David S . Miller,
linux-bluetooth, linux-wpan, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
The WARN_ON_ONCE check on id is off-by-one, it should be greater or equal
to LOWPAN_IPHC_CTX_TABLE_SIZE and not greater than. Fix this.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
net/6lowpan/debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/6lowpan/debugfs.c b/net/6lowpan/debugfs.c
index 1c140af06d52..a510bed8165b 100644
--- a/net/6lowpan/debugfs.c
+++ b/net/6lowpan/debugfs.c
@@ -170,7 +170,7 @@ static void lowpan_dev_debugfs_ctx_init(struct net_device *dev,
struct dentry *root;
char buf[32];
- WARN_ON_ONCE(id > LOWPAN_IPHC_CTX_TABLE_SIZE);
+ WARN_ON_ONCE(id >= LOWPAN_IPHC_CTX_TABLE_SIZE);
sprintf(buf, "%d", id);
--
2.20.1
^ permalink raw reply related
* Re: Removing skb_orphan() from ip_rcv_core()
From: Jamal Hadi Salim @ 2019-06-24 14:47 UTC (permalink / raw)
To: Joe Stringer, Eric Dumazet, Florian Westphal
Cc: netdev, john fastabend, Daniel Borkmann, Lorenz Bauer,
Jakub Sitnicki, Paolo Abeni
In-Reply-To: <CAOftzPisP-3jN8drC6RXcTigXJjdwEnvTRvTHR-Kv4LKn4rhQQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1567 bytes --]
On 2019-06-21 1:58 p.m., Joe Stringer wrote:
> Hi folks, picking this up again..
[..]
> During LSFMM, it seemed like no-one knew quite why the skb_orphan() is
> necessary in that path in the current version of the code, and that we
> may be able to remove it. Florian, I know you weren't in the room for
> that discussion, so raising it again now with a stack trace, Do you
> have some sense what's going on here and whether there's a path
> towards removing it from this path or allowing the skb->sk to be
> retained during ip_rcv() in some conditions?
Sorry - I havent followed the discussion but saw your email over
the weekend and wanted to be at work to refresh my memory on some
code. For maybe 2-3 years we have deployed the tproxy
equivalent as a tc action on ingress (with no netfilter dependency).
And, of course, we had to work around that specific code you are
referring to - we didnt remove it. The tc action code increments
the sk refcount and sets the tc index. The net core doesnt orphan
the skb if a speacial tc index value is set (see attached patch)
I never bothered up streaming the patch because the hack is a bit
embarrassing (but worked ;->); and never posted the action code
either because i thought this was just us that had this requirement.
I am glad other people see the need for this feature. Is there effort
to make this _not_ depend on iptables/netfilter? I am guessing if you
want to do this from ebpf (tc or xdp) that is a requirement.
Our need was with tcp at the time; so left udp dependency on netfilter
alone.
cheers,
jamal
[-- Attachment #2: tp_tcindex.patch --]
[-- Type: text/x-patch, Size: 1927 bytes --]
commit 4d130b0a883b4aebc36a88ca116746594e176c6a
Author: Jamal Hadi Salim <hadi@mojatatu.com>
Date: Fri Nov 25 15:45:48 2016 -0400
transparent proxy workaround so we can get the tcaction to work
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index fa2dc8f692c6..29b303dbbfd9 100644
--- a/net/ipv4/ip_input.c
+++ b/net/ipv4/ip_input.c
@@ -482,8 +482,11 @@ int ip_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt,
memset(IPCB(skb), 0, sizeof(struct inet_skb_parm));
IPCB(skb)->iif = skb->skb_iif;
- /* Must drop socket now because of tproxy. */
- skb_orphan(skb);
+ /* Must drop socket now because of tproxy,
+ * if we didnt set it already as usable
+ * */
+ if(skb->tc_index != 0xFFFF)
+ skb_orphan(skb);
return NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
net, NULL, skb, dev, NULL,
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index 9ee208a348f5..10148f2eec03 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -77,12 +77,16 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
u32 pkt_len;
struct inet6_dev *idev;
struct net *net = dev_net(skb->dev);
+ struct sock *orig_sk = NULL;
if (skb->pkt_type == PACKET_OTHERHOST) {
kfree_skb(skb);
return NET_RX_DROP;
}
+ if(skb->tc_index == 0xFFFF)
+ orig_sk = skb->sk;
+
rcu_read_lock();
idev = __in6_dev_get(skb->dev);
@@ -202,8 +206,17 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
rcu_read_unlock();
+ if (skb->tc_index == 0xFFFF && !skb->sk && orig_sk)
+ {
+ skb_orphan(skb);
+ skb->sk = orig_sk;
+ skb->destructor = sock_edemux;
+ atomic_inc_not_zero(&skb->sk->sk_refcnt);
+ }
+
/* Must drop socket now because of tproxy. */
- skb_orphan(skb);
+ if(skb->tc_index != 0xFFFF)
+ skb_orphan(skb);
return NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
net, NULL, skb, dev, NULL,
^ permalink raw reply related
* Re: [PATCH net] tipc: remove the unnecessary msg->req check from tipc_nl_compat_bearer_set
From: David Miller @ 2019-06-24 14:35 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, jon.maloy, ying.xue, tipc-discussion
In-Reply-To: <a4f39065f0b1cb13da2159339c08d78cb61f88d9.1561363362.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 24 Jun 2019 16:02:42 +0800
> tipc_nl_compat_bearer_set() is only called by tipc_nl_compat_link_set()
> which already does the check for msg->req check, so remove it from
> tipc_nl_compat_bearer_set(), and do the same in tipc_nl_compat_media_set().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Is this really appropriate as a fix for 'net'? Seems more like net-next material
to me.
^ permalink raw reply
* Re: [PATCH 05/11] ixgbe: add offset to zca_free
From: Björn Töpel @ 2019-06-24 14:32 UTC (permalink / raw)
To: Kevin Laatz
Cc: Netdev, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, bpf, intel-wired-lan,
Bruce Richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-6-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 at 19:25, Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch adds the offset param to for zero_copy_allocator to
> ixgbe_zca_free. This change is required to calculate the handle, otherwise,
> this function will not work in unaligned chunk mode since we can't easily mask
> back to the original handle in unaligned chunk mode.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h | 3 ++-
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 8 ++++----
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> index d93a690aff74..49702e2a4360 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_txrx_common.h
> @@ -33,7 +33,8 @@ struct xdp_umem *ixgbe_xsk_umem(struct ixgbe_adapter *adapter,
> int ixgbe_xsk_umem_setup(struct ixgbe_adapter *adapter, struct xdp_umem *umem,
> u16 qid);
>
> -void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle);
> +void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle,
> + off_t off);
>
> void ixgbe_alloc_rx_buffers_zc(struct ixgbe_ring *rx_ring, u16 cleaned_count);
> int ixgbe_clean_rx_irq_zc(struct ixgbe_q_vector *q_vector,
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> index 49536adafe8e..1ec02077ccb2 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> @@ -268,16 +268,16 @@ static void ixgbe_reuse_rx_buffer_zc(struct ixgbe_ring *rx_ring,
> obi->skb = NULL;
> }
>
> -void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> +void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle,
> + off_t off)
> {
> struct ixgbe_rx_buffer *bi;
> struct ixgbe_ring *rx_ring;
> - u64 hr, mask;
> + u64 hr;
> u16 nta;
>
> rx_ring = container_of(alloc, struct ixgbe_ring, zca);
> hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> - mask = rx_ring->xsk_umem->chunk_mask;
>
> nta = rx_ring->next_to_alloc;
> bi = rx_ring->rx_buffer_info;
> @@ -285,7 +285,7 @@ void ixgbe_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> nta++;
> rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
>
> - handle &= mask;
> + handle -= off;
>
> bi->dma = xdp_umem_get_dma(rx_ring->xsk_umem, handle);
> bi->dma += hr;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 04/11] i40e: add offset to zca_free
From: Björn Töpel @ 2019-06-24 14:32 UTC (permalink / raw)
To: Kevin Laatz
Cc: Netdev, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, bpf, intel-wired-lan,
Bruce Richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-5-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 at 19:25, Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch adds the offset param to for zero_copy_allocator to
> i40e_zca_free. This change is required to calculate the handle, otherwise,
> this function will not work in unaligned chunk mode since we can't easily mask
> back to the original handle in unaligned chunk mode.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 8 ++++----
> drivers/net/ethernet/intel/i40e/i40e_xsk.h | 3 ++-
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index c89e692e8663..8c281f356293 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -438,16 +438,16 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
> * @alloc: Zero-copy allocator
> * @handle: Buffer handle
> **/
> -void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> +void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle,
> + off_t off)
> {
> struct i40e_rx_buffer *bi;
> struct i40e_ring *rx_ring;
> - u64 hr, mask;
> + u64 hr;
> u16 nta;
>
> rx_ring = container_of(alloc, struct i40e_ring, zca);
> hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> - mask = rx_ring->xsk_umem->chunk_mask;
>
> nta = rx_ring->next_to_alloc;
> bi = &rx_ring->rx_bi[nta];
> @@ -455,7 +455,7 @@ void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle)
> nta++;
> rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
>
> - handle &= mask;
> + handle -= off;
>
> bi->dma = xdp_umem_get_dma(rx_ring->xsk_umem, handle);
> bi->dma += hr;
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.h b/drivers/net/ethernet/intel/i40e/i40e_xsk.h
> index 8cc0a2e7d9a2..85691dc9ac42 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.h
> @@ -12,7 +12,8 @@ int i40e_queue_pair_disable(struct i40e_vsi *vsi, int queue_pair);
> int i40e_queue_pair_enable(struct i40e_vsi *vsi, int queue_pair);
> int i40e_xsk_umem_setup(struct i40e_vsi *vsi, struct xdp_umem *umem,
> u16 qid);
> -void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle);
> +void i40e_zca_free(struct zero_copy_allocator *alloc, unsigned long handle,
> + off_t off);
> bool i40e_alloc_rx_buffers_zc(struct i40e_ring *rx_ring, u16 cleaned_count);
> int i40e_clean_rx_irq_zc(struct i40e_ring *rx_ring, int budget);
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 03/11] xdp: add offset param to zero_copy_allocator
From: Björn Töpel @ 2019-06-24 14:31 UTC (permalink / raw)
To: Kevin Laatz
Cc: Netdev, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, bpf, intel-wired-lan,
Bruce Richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-4-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 at 19:25, Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> This patch adds an offset parameter for zero_copy_allocator.
>
> This change is required for the unaligned chunk mode which will come later
> in this patch set. The offset parameter is required for calculating the
> original handle in unaligned mode since we can't easily mask back to it
> like in the aligned case.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> include/net/xdp.h | 3 ++-
> net/core/xdp.c | 11 ++++++-----
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index 0f25b3675c5c..ea801fd2bf98 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -53,7 +53,8 @@ struct xdp_mem_info {
> struct page_pool;
>
> struct zero_copy_allocator {
> - void (*free)(struct zero_copy_allocator *zca, unsigned long handle);
> + void (*free)(struct zero_copy_allocator *zca, unsigned long handle,
> + off_t off);
> };
>
> struct xdp_rxq_info {
> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 4b2b194f4f1f..a77a7162d213 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -322,7 +322,7 @@ EXPORT_SYMBOL_GPL(xdp_rxq_info_reg_mem_model);
> * of xdp_frames/pages in those cases.
> */
> static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> - unsigned long handle)
> + unsigned long handle, off_t off)
> {
> struct xdp_mem_allocator *xa;
> struct page *page;
> @@ -353,7 +353,7 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> rcu_read_lock();
> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> - xa->zc_alloc->free(xa->zc_alloc, handle);
> + xa->zc_alloc->free(xa->zc_alloc, handle, off);
> rcu_read_unlock();
> default:
> /* Not possible, checked in xdp_rxq_info_reg_mem_model() */
> @@ -363,19 +363,20 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
>
> void xdp_return_frame(struct xdp_frame *xdpf)
> {
> - __xdp_return(xdpf->data, &xdpf->mem, false, 0);
> + __xdp_return(xdpf->data, &xdpf->mem, false, 0, 0);
> }
> EXPORT_SYMBOL_GPL(xdp_return_frame);
>
> void xdp_return_frame_rx_napi(struct xdp_frame *xdpf)
> {
> - __xdp_return(xdpf->data, &xdpf->mem, true, 0);
> + __xdp_return(xdpf->data, &xdpf->mem, true, 0, 0);
> }
> EXPORT_SYMBOL_GPL(xdp_return_frame_rx_napi);
>
> void xdp_return_buff(struct xdp_buff *xdp)
> {
> - __xdp_return(xdp->data, &xdp->rxq->mem, true, xdp->handle);
> + __xdp_return(xdp->data, &xdp->rxq->mem, true, xdp->handle,
> + xdp->data - xdp->data_hard_start);
> }
> EXPORT_SYMBOL_GPL(xdp_return_buff);
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH rdma-next v1 09/12] IB/mlx5: Register DEVX with mlx5_core to get async events
From: Jason Gunthorpe @ 2019-06-24 14:30 UTC (permalink / raw)
To: Yishai Hadas
Cc: Leon Romanovsky, Doug Ledford, Leon Romanovsky, RDMA mailing list,
Yishai Hadas, Saeed Mahameed, linux-netdev
In-Reply-To: <3bc6780f-5c3e-b121-e4ea-f7b8f00cbd13@dev.mellanox.co.il>
On Mon, Jun 24, 2019 at 04:36:44PM +0300, Yishai Hadas wrote:
> On 6/24/2019 2:52 PM, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2019 at 08:15:37PM +0300, Leon Romanovsky wrote:
> > > void __mlx5_ib_remove(struct mlx5_ib_dev *dev,
> > > diff --git a/drivers/infiniband/hw/mlx5/mlx5_ib.h b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > > index 9cf23ae6324e..556af34b788b 100644
> > > +++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h
> > > @@ -944,6 +944,13 @@ struct mlx5_ib_pf_eq {
> > > mempool_t *pool;
> > > };
> > > +struct mlx5_devx_event_table {
> > > + struct mlx5_nb devx_nb;
> > > + /* serialize updating the event_xa */
> > > + struct mutex event_xa_lock;
> > > + struct xarray event_xa;
> > > +};
> > > +
> > > struct mlx5_ib_dev {
> > > struct ib_device ib_dev;
> > > struct mlx5_core_dev *mdev;
> > > @@ -994,6 +1001,7 @@ struct mlx5_ib_dev {
> > > struct mlx5_srq_table srq_table;
> > > struct mlx5_async_ctx async_ctx;
> > > int free_port;
> > > + struct mlx5_devx_event_table devx_event_table;
> >
> > I really question if adding all these structs really does anything for
> > readability..
> >
>
> I would prefer this option to add only one structure (i.e.
> mlx5_devx_event_table) on ib_dev, it will hold internally the other related
> stuff.
It seems confounding but generally is the style in this struct :\
Jason
^ permalink raw reply
* Re: [PATCH 02/11] ixgbe: simplify Rx buffer recycle
From: Björn Töpel @ 2019-06-24 14:30 UTC (permalink / raw)
To: Kevin Laatz
Cc: Netdev, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, bpf, intel-wired-lan,
Bruce Richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-3-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 at 19:25, Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> Currently, the dma, addr and handle are modified when we reuse Rx buffers
> in zero-copy mode. However, this is not required as the inputs to the
> function are copies, not the original values themselves. As we use the
> copies within the function, we can use the original 'obi' values
> directly without having to mask and add the headroom.
>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> index bfe95ce0bd7f..49536adafe8e 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_xsk.c
> @@ -251,8 +251,6 @@ ixgbe_rx_buffer *ixgbe_get_rx_buffer_zc(struct ixgbe_ring *rx_ring,
> static void ixgbe_reuse_rx_buffer_zc(struct ixgbe_ring *rx_ring,
> struct ixgbe_rx_buffer *obi)
> {
> - unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
> - u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> u16 nta = rx_ring->next_to_alloc;
> struct ixgbe_rx_buffer *nbi;
>
> @@ -262,14 +260,9 @@ static void ixgbe_reuse_rx_buffer_zc(struct ixgbe_ring *rx_ring,
> rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
>
> /* transfer page from old buffer to new buffer */
> - nbi->dma = obi->dma & mask;
> - nbi->dma += hr;
> -
> - nbi->addr = (void *)((unsigned long)obi->addr & mask);
> - nbi->addr += hr;
> -
> - nbi->handle = obi->handle & mask;
> - nbi->handle += rx_ring->xsk_umem->headroom;
> + nbi->dma = obi->dma;
> + nbi->addr = obi->addr;
> + nbi->handle = obi->handle;
>
> obi->addr = NULL;
> obi->skb = NULL;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH rdma-next v1 08/12] IB/mlx5: Introduce MLX5_IB_OBJECT_DEVX_ASYNC_EVENT_FD
From: Jason Gunthorpe @ 2019-06-24 14:30 UTC (permalink / raw)
To: Yishai Hadas
Cc: Doug Ledford, Leon Romanovsky, RDMA mailing list, Yishai Hadas,
Saeed Mahameed, linux-netdev
In-Reply-To: <baae74b9-94ff-9f5a-0992-c1eec5049306@dev.mellanox.co.il>
On Mon, Jun 24, 2019 at 04:25:37PM +0300, Yishai Hadas wrote:
> On 6/24/2019 2:51 PM, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2019 at 08:15:36PM +0300, Leon Romanovsky wrote:
> > > From: Yishai Hadas <yishaih@mellanox.com>
> > >
> > > Introduce MLX5_IB_OBJECT_DEVX_ASYNC_EVENT_FD and its initial
> > > implementation.
> > >
> > > This object is from type class FD and will be used to read DEVX
> > > async events.
> > >
> > > Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
> > > Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> > > drivers/infiniband/hw/mlx5/devx.c | 112 ++++++++++++++++++++--
> > > include/uapi/rdma/mlx5_user_ioctl_cmds.h | 10 ++
> > > include/uapi/rdma/mlx5_user_ioctl_verbs.h | 4 +
> > > 3 files changed, 116 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/infiniband/hw/mlx5/devx.c b/drivers/infiniband/hw/mlx5/devx.c
> > > index 80b42d069328..1815ce0f8daf 100644
> > > +++ b/drivers/infiniband/hw/mlx5/devx.c
> > > @@ -33,6 +33,24 @@ struct devx_async_data {
> > > struct mlx5_ib_uapi_devx_async_cmd_hdr hdr;
> > > };
> > > +struct devx_async_event_queue {
> >
> > It seems to be a mistake to try and re-use the async_event_queue for
> > both cmd and event, as they use it very differently and don't even
> > store the same things in the event_list. I think it is bettter to just
> > inline this into devx_async_event_file (and inline the old struct in
> > the cmd file
> >
>
> How about having another struct with all the event's queue fields together ?
> this has the benefit of having all those related fields in one place and
> leave the cmd as is.
>
> Alternatively,
> We can inline the event stuff under devx_async_event_file and leave the cmd
> for now under a struct as it's not directly related to this series.
I would probbaly do this
> > > + spinlock_t lock;
> > > + wait_queue_head_t poll_wait;
> > > + struct list_head event_list;
> > > + atomic_t bytes_in_use;
> > > + u8 is_destroyed:1;
> > > + u32 flags;
> > > +};
> >
> > All the flags testing is ugly, why not just add another bitfield?
>
> The flags are coming from user space and have their different name space, I
> prefer to not mix with kernel ones. (i.e. is_destroyed).
> Makes sense ?
No, better to add a bitfield than store the raw flags and another
bitfield.
> > > diff --git a/include/uapi/rdma/mlx5_user_ioctl_verbs.h b/include/uapi/rdma/mlx5_user_ioctl_verbs.h
> > > index a8f34c237458..57beea4589e4 100644
> > > +++ b/include/uapi/rdma/mlx5_user_ioctl_verbs.h
> > > @@ -63,5 +63,9 @@ enum mlx5_ib_uapi_dm_type {
> > > MLX5_IB_UAPI_DM_TYPE_HEADER_MODIFY_SW_ICM,
> > > };
> > > +enum mlx5_ib_uapi_devx_create_event_channel_flags {
> > > + MLX5_IB_UAPI_DEVX_CREATE_EVENT_CHANNEL_FLAGS_OMIT_EV_DATA = 1
> > > << 0,
> >
> > Maybe this name is too long
>
> Quite long but follows the name scheme having the UAPI prefix.
> Any shorter suggestion ?
>
I think you should shorten it
Jason
^ permalink raw reply
* Re: [net-next] tipc: fix missing indentation in source code
From: David Miller @ 2019-06-24 14:30 UTC (permalink / raw)
To: john.rutherford; +Cc: netdev, tipc-discussion
In-Reply-To: <20190624040123.32337-1-john.rutherford@dektech.com.au>
From: John Rutherford <john.rutherford@dektech.com.au>
Date: Mon, 24 Jun 2019 14:01:23 +1000
> Fix misalignment of policy statement in netlink.c due to automatic
> spatch code transformation.
>
> Fixes: 3b0f31f2b8c9 ("genetlink: make policy common to family")
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: John Rutherford <john.rutherford@dektech.com.au>
Applied.
^ permalink raw reply
* Re: [PATCH 01/11] i40e: simplify Rx buffer recycle
From: Björn Töpel @ 2019-06-24 14:29 UTC (permalink / raw)
To: Kevin Laatz
Cc: Netdev, Alexei Starovoitov, Daniel Borkmann,
Björn Töpel, Karlsson, Magnus, bpf, intel-wired-lan,
Bruce Richardson, ciara.loftus
In-Reply-To: <20190620090958.2135-2-kevin.laatz@intel.com>
On Thu, 20 Jun 2019 at 19:25, Kevin Laatz <kevin.laatz@intel.com> wrote:
>
> Currently, the dma, addr and handle are modified when we reuse Rx buffers
> in zero-copy mode. However, this is not required as the inputs to the
> function are copies, not the original values themselves. As we use the
> copies within the function, we can use the original 'old_bi' values
> directly without having to mask and add the headroom.
>
I like that the required change was turned into a cleanup! Nice!
Acked-by: Björn Töpel <bjorn.topel@intel.com>
> Signed-off-by: Kevin Laatz <kevin.laatz@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_xsk.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> index 1b17486543ac..c89e692e8663 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
> @@ -419,8 +419,6 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
> struct i40e_rx_buffer *old_bi)
> {
> struct i40e_rx_buffer *new_bi = &rx_ring->rx_bi[rx_ring->next_to_alloc];
> - unsigned long mask = (unsigned long)rx_ring->xsk_umem->chunk_mask;
> - u64 hr = rx_ring->xsk_umem->headroom + XDP_PACKET_HEADROOM;
> u16 nta = rx_ring->next_to_alloc;
>
> /* update, and store next to alloc */
> @@ -428,14 +426,9 @@ static void i40e_reuse_rx_buffer_zc(struct i40e_ring *rx_ring,
> rx_ring->next_to_alloc = (nta < rx_ring->count) ? nta : 0;
>
> /* transfer page from old buffer to new buffer */
> - new_bi->dma = old_bi->dma & mask;
> - new_bi->dma += hr;
> -
> - new_bi->addr = (void *)((unsigned long)old_bi->addr & mask);
> - new_bi->addr += hr;
> -
> - new_bi->handle = old_bi->handle & mask;
> - new_bi->handle += rx_ring->xsk_umem->headroom;
> + new_bi->dma = old_bi->dma;
> + new_bi->addr = old_bi->addr;
> + new_bi->handle = old_bi->handle;
>
> old_bi->addr = NULL;
> }
> --
> 2.17.1
>
^ permalink raw reply
* Re: [net-next v2] tipc: add loopback device tracking
From: David Miller @ 2019-06-24 14:29 UTC (permalink / raw)
To: john.rutherford; +Cc: netdev
In-Reply-To: <20190624064435.22357-1-john.rutherford@dektech.com.au>
From: john.rutherford@dektech.com.au
Date: Mon, 24 Jun 2019 16:44:35 +1000
> Since node internal messages are passed directly to socket it is not
> possible to observe this message exchange via tcpdump or wireshark.
>
> We now remedy this by making it possible to clone such messages and send
> the clones to the loopback interface. The clones are dropped at reception
> and have no functional role except making the traffic visible.
>
> The feature is turned on/off by enabling/disabling the loopback "bearer"
> "eth:lo".
>
> Acked-by: Jon Maloy <jon.maloy@ericsson.com>
> Signed-off-by: John Rutherford <john.rutherford@dektech.com.au>
What a waste, just clone the packet, attach loopback to it, and go:
if (dev_nit_active(loopback_dev))
dev_queue_xmit_nit(skb, loopback_dev);
^ permalink raw reply
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node
From: Andrew Lunn @ 2019-06-24 14:26 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Claudiu Manoil, David S . Miller, devicetree@vger.kernel.org,
netdev@vger.kernel.org, Alexandru Marginean,
linux-kernel@vger.kernel.org, UNGLinuxDriver@microchip.com,
Allan Nielsen, Rob Herring, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190624115558.GA5690@piout.net>
> > Yeah, there are 2 ethernet controller ports (managed by the enetc driver)
> > connected inside the SoC via SGMII links to 2 of the switch ports, one of
> > these switch ports can be configured as CPU port (with follow-up patches).
> >
> > This configuration may look prettier on DSA, but the main restriction here
> > is that the entire functionality is provided by the ocelot driver which is a
> > switchdev driver. I don't think it would be a good idea to copy-paste code
> > from ocelot to a separate dsa driver.
> >
>
> We should probably make the ocelot driver a DSA driver then...
Hi Claudiu, Alexandre
An important part of DSA is being able to direct frames out specific
ports when they ingress via the CPU port. Does the silicon support
this? At the moment, i think it is using polled IO.
Andrew
^ permalink raw reply
* Re: [PATCH V2] net: ethernet: ti: cpsw: Fix suspend/resume break
From: David Miller @ 2019-06-24 14:23 UTC (permalink / raw)
To: j-keerthy
Cc: ivan.khoronzhuk, andrew, ilias.apalodimas, linux-kernel, netdev,
linux-omap, t-kristo, grygorii.strashko, nsekhar
In-Reply-To: <20190624051619.20146-1-j-keerthy@ti.com>
From: Keerthy <j-keerthy@ti.com>
Date: Mon, 24 Jun 2019 10:46:19 +0530
> Commit bfe59032bd6127ee190edb30be9381a01765b958 ("net: ethernet:
> ti: cpsw: use cpsw as drv data")changes
> the driver data to struct cpsw_common *cpsw. This is done
> only in probe/remove but the suspend/resume functions are
> still left with struct net_device *ndev. Hence fix both
> suspend & resume also to fetch the updated driver data.
>
> Fixes: bfe59032bd6127ee1 ("net: ethernet: ti: cpsw: use cpsw as drv data")
> Signed-off-by: Keerthy <j-keerthy@ti.com>
Applied but please make it clear that changes are targetting net-next in the
future by saying "[PATCH net-next v2] ...." in your Subject line.
Thank you.
^ permalink raw reply
* Re: [PATCH bpf-next] bpftool: Add BPF_F_QUERY_EFFECTIVE support in bpftool cgroup [show|tree]
From: Daniel Borkmann @ 2019-06-24 14:22 UTC (permalink / raw)
To: Takshak Chahande, netdev; +Cc: ast, rdna, kernel-team
In-Reply-To: <20190621223311.1380295-1-ctakshak@fb.com>
On 06/22/2019 12:33 AM, Takshak Chahande wrote:
> With different bpf attach_flags available to attach bpf programs specially
> with BPF_F_ALLOW_OVERRIDE and BPF_F_ALLOW_MULTI, the list of effective
> bpf-programs available to any sub-cgroups really needs to be available for
> easy debugging.
>
> Using BPF_F_QUERY_EFFECTIVE flag, one can get the list of not only attached
> bpf-programs to a cgroup but also the inherited ones from parent cgroup.
>
> So "-e" option is introduced to use BPF_F_QUERY_EFFECTIVE query flag here to
> list all the effective bpf-programs available for execution at a specified
> cgroup.
>
> Reused modified test program test_cgroup_attach from tools/testing/selftests/bpf:
> # ./test_cgroup_attach
>
> With old bpftool (without -e option):
>
> # bpftool cgroup show /sys/fs/cgroup/cgroup-test-work-dir/cg1/
> ID AttachType AttachFlags Name
> 271 egress multi pkt_cntr_1
> 272 egress multi pkt_cntr_2
>
> Attached new program pkt_cntr_4 in cg2 gives following:
>
> # bpftool cgroup show /sys/fs/cgroup/cgroup-test-work-dir/cg1/cg2
> ID AttachType AttachFlags Name
> 273 egress override pkt_cntr_4
>
> And with new "-e" option it shows all effective programs for cg2:
>
> # bpftool -e cgroup show /sys/fs/cgroup/cgroup-test-work-dir/cg1/cg2
> ID AttachType AttachFlags Name
> 273 egress override pkt_cntr_4
> 271 egress override pkt_cntr_1
> 272 egress override pkt_cntr_2
>
> Signed-off-by: Takshak Chahande <ctakshak@fb.com>
> Acked-by: Andrey Ignatov <rdna@fb.com>
Applied, thanks!
^ 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