* [PATCH net-next v2 2/6] net/faraday: Make EDO{R,T}R bits configurable
From: Joel Stanley @ 2016-09-21 23:04 UTC (permalink / raw)
To: davem; +Cc: clg, Andrew Jeffery, gwshan, andrew, netdev, linux-kernel, benh
In-Reply-To: <20160921230503.23309-1-joel@jms.id.au>
From: Andrew Jeffery <andrew@aj.id.au>
These bits are #defined at a fixed location. In order to support future
hardware that has chosen to move these bits around move the bits into a
member of the struct ftgmac100.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 40 +++++++++++++++++++++-----------
drivers/net/ethernet/faraday/ftgmac100.h | 2 --
2 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 40622567159a..62a88d1a1f99 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -79,6 +79,9 @@ struct ftgmac100 {
int int_mask_all;
bool use_ncsi;
bool enabled;
+
+ u32 rxdes0_edorr_mask;
+ u32 txdes0_edotr_mask;
};
static int ftgmac100_alloc_rx_page(struct ftgmac100 *priv,
@@ -259,10 +262,11 @@ static bool ftgmac100_rxdes_packet_ready(struct ftgmac100_rxdes *rxdes)
return rxdes->rxdes0 & cpu_to_le32(FTGMAC100_RXDES0_RXPKT_RDY);
}
-static void ftgmac100_rxdes_set_dma_own(struct ftgmac100_rxdes *rxdes)
+static void ftgmac100_rxdes_set_dma_own(const struct ftgmac100 *priv,
+ struct ftgmac100_rxdes *rxdes)
{
/* clear status bits */
- rxdes->rxdes0 &= cpu_to_le32(FTGMAC100_RXDES0_EDORR);
+ rxdes->rxdes0 &= cpu_to_le32(priv->rxdes0_edorr_mask);
}
static bool ftgmac100_rxdes_rx_error(struct ftgmac100_rxdes *rxdes)
@@ -300,9 +304,10 @@ static bool ftgmac100_rxdes_multicast(struct ftgmac100_rxdes *rxdes)
return rxdes->rxdes0 & cpu_to_le32(FTGMAC100_RXDES0_MULTICAST);
}
-static void ftgmac100_rxdes_set_end_of_ring(struct ftgmac100_rxdes *rxdes)
+static void ftgmac100_rxdes_set_end_of_ring(const struct ftgmac100 *priv,
+ struct ftgmac100_rxdes *rxdes)
{
- rxdes->rxdes0 |= cpu_to_le32(FTGMAC100_RXDES0_EDORR);
+ rxdes->rxdes0 |= cpu_to_le32(priv->rxdes0_edorr_mask);
}
static void ftgmac100_rxdes_set_dma_addr(struct ftgmac100_rxdes *rxdes,
@@ -393,7 +398,7 @@ ftgmac100_rx_locate_first_segment(struct ftgmac100 *priv)
if (ftgmac100_rxdes_first_segment(rxdes))
return rxdes;
- ftgmac100_rxdes_set_dma_own(rxdes);
+ ftgmac100_rxdes_set_dma_own(priv, rxdes);
ftgmac100_rx_pointer_advance(priv);
rxdes = ftgmac100_current_rxdes(priv);
}
@@ -464,7 +469,7 @@ static void ftgmac100_rx_drop_packet(struct ftgmac100 *priv)
if (ftgmac100_rxdes_last_segment(rxdes))
done = true;
- ftgmac100_rxdes_set_dma_own(rxdes);
+ ftgmac100_rxdes_set_dma_own(priv, rxdes);
ftgmac100_rx_pointer_advance(priv);
rxdes = ftgmac100_current_rxdes(priv);
} while (!done && ftgmac100_rxdes_packet_ready(rxdes));
@@ -556,10 +561,11 @@ static bool ftgmac100_rx_packet(struct ftgmac100 *priv, int *processed)
/******************************************************************************
* internal functions (transmit descriptor)
*****************************************************************************/
-static void ftgmac100_txdes_reset(struct ftgmac100_txdes *txdes)
+static void ftgmac100_txdes_reset(const struct ftgmac100 *priv,
+ struct ftgmac100_txdes *txdes)
{
/* clear all except end of ring bit */
- txdes->txdes0 &= cpu_to_le32(FTGMAC100_TXDES0_EDOTR);
+ txdes->txdes0 &= cpu_to_le32(priv->txdes0_edotr_mask);
txdes->txdes1 = 0;
txdes->txdes2 = 0;
txdes->txdes3 = 0;
@@ -580,9 +586,10 @@ static void ftgmac100_txdes_set_dma_own(struct ftgmac100_txdes *txdes)
txdes->txdes0 |= cpu_to_le32(FTGMAC100_TXDES0_TXDMA_OWN);
}
-static void ftgmac100_txdes_set_end_of_ring(struct ftgmac100_txdes *txdes)
+static void ftgmac100_txdes_set_end_of_ring(const struct ftgmac100 *priv,
+ struct ftgmac100_txdes *txdes)
{
- txdes->txdes0 |= cpu_to_le32(FTGMAC100_TXDES0_EDOTR);
+ txdes->txdes0 |= cpu_to_le32(priv->txdes0_edotr_mask);
}
static void ftgmac100_txdes_set_first_segment(struct ftgmac100_txdes *txdes)
@@ -701,7 +708,7 @@ static bool ftgmac100_tx_complete_packet(struct ftgmac100 *priv)
dev_kfree_skb(skb);
- ftgmac100_txdes_reset(txdes);
+ ftgmac100_txdes_reset(priv, txdes);
ftgmac100_tx_clean_pointer_advance(priv);
@@ -792,7 +799,7 @@ static int ftgmac100_alloc_rx_page(struct ftgmac100 *priv,
ftgmac100_rxdes_set_page(priv, rxdes, page);
ftgmac100_rxdes_set_dma_addr(rxdes, map);
- ftgmac100_rxdes_set_dma_own(rxdes);
+ ftgmac100_rxdes_set_dma_own(priv, rxdes);
return 0;
}
@@ -839,7 +846,8 @@ static int ftgmac100_alloc_buffers(struct ftgmac100 *priv)
return -ENOMEM;
/* initialize RX ring */
- ftgmac100_rxdes_set_end_of_ring(&priv->descs->rxdes[RX_QUEUE_ENTRIES - 1]);
+ ftgmac100_rxdes_set_end_of_ring(priv,
+ &priv->descs->rxdes[RX_QUEUE_ENTRIES - 1]);
for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
struct ftgmac100_rxdes *rxdes = &priv->descs->rxdes[i];
@@ -849,7 +857,8 @@ static int ftgmac100_alloc_buffers(struct ftgmac100 *priv)
}
/* initialize TX ring */
- ftgmac100_txdes_set_end_of_ring(&priv->descs->txdes[TX_QUEUE_ENTRIES - 1]);
+ ftgmac100_txdes_set_end_of_ring(priv,
+ &priv->descs->txdes[TX_QUEUE_ENTRIES - 1]);
return 0;
err:
@@ -1336,6 +1345,9 @@ static int ftgmac100_probe(struct platform_device *pdev)
priv->netdev = netdev;
priv->dev = &pdev->dev;
+ priv->rxdes0_edorr_mask = BIT(15);
+ priv->txdes0_edotr_mask = BIT(15);
+
spin_lock_init(&priv->tx_lock);
/* initialize NAPI */
diff --git a/drivers/net/ethernet/faraday/ftgmac100.h b/drivers/net/ethernet/faraday/ftgmac100.h
index 13408d448b05..c258586ce4a4 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.h
+++ b/drivers/net/ethernet/faraday/ftgmac100.h
@@ -189,7 +189,6 @@ struct ftgmac100_txdes {
} __attribute__ ((aligned(16)));
#define FTGMAC100_TXDES0_TXBUF_SIZE(x) ((x) & 0x3fff)
-#define FTGMAC100_TXDES0_EDOTR (1 << 15)
#define FTGMAC100_TXDES0_CRC_ERR (1 << 19)
#define FTGMAC100_TXDES0_LTS (1 << 28)
#define FTGMAC100_TXDES0_FTS (1 << 29)
@@ -215,7 +214,6 @@ struct ftgmac100_rxdes {
} __attribute__ ((aligned(16)));
#define FTGMAC100_RXDES0_VDBC 0x3fff
-#define FTGMAC100_RXDES0_EDORR (1 << 15)
#define FTGMAC100_RXDES0_MULTICAST (1 << 16)
#define FTGMAC100_RXDES0_BROADCAST (1 << 17)
#define FTGMAC100_RXDES0_RX_ERR (1 << 18)
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 0/6] ftgmac100 support for ast2500
From: Joel Stanley @ 2016-09-21 23:04 UTC (permalink / raw)
To: davem; +Cc: clg, gwshan, andrew, andrew, netdev, linux-kernel, benh
Hello Dave,
This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
ast2500 SoCs. In particular, they ensure the driver works correctly on the
ast2500 where the MAC block has seen some changes in register layout.
They have been tested on ast2400 and ast2500 systems with the NCSI stack and
with a directly attached PHY.
V2 reworks the two patches relating to PHYSTS_CHG into the one patch that
disables the interrupt instead of playing with interrupt sensitivity. I kept
patch 4 'net/faraday: Clear stale interrupts' which was first introduced to
clear the stale PHYSTS_CHG interrupt, as it helps keep us safe from unhygienic
(vendor) bootloaders.
Cheers,
Joel
Andrew Jeffery (2):
net/faraday: Separate rx page storage from rxdesc
net/faraday: Make EDO{R,T}R bits configurable
Gavin Shan (1):
net/faraday: Clear stale interrupts
Joel Stanley (3):
net/faraday: Adapt for Aspeed SoCs
net/faraday: Configure old MDIO interface on Aspeed SoCs
net/faraday: Mask out PHYSTS_CHG interrupt
drivers/net/ethernet/faraday/ftgmac100.c | 97 +++++++++++++++++++++++---------
drivers/net/ethernet/faraday/ftgmac100.h | 8 ++-
2 files changed, 75 insertions(+), 30 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next v2 5/6] net/faraday: Configure old MDIO interface on Aspeed SoCs
From: Joel Stanley @ 2016-09-21 23:05 UTC (permalink / raw)
To: davem; +Cc: clg, gwshan, andrew, andrew, netdev, linux-kernel, benh
In-Reply-To: <20160921230503.23309-1-joel@jms.id.au>
The Aspeed SoCs have a new MDIO interface as an option in the G4 and G5
SoCs. The old one is still available, so select it in order to remain
compatible with the ftgmac100 driver.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 9 +++++++++
drivers/net/ethernet/faraday/ftgmac100.h | 5 +++++
2 files changed, 14 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 189373743ddf..e3653b14008a 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1252,12 +1252,21 @@ static int ftgmac100_setup_mdio(struct net_device *netdev)
struct ftgmac100 *priv = netdev_priv(netdev);
struct platform_device *pdev = to_platform_device(priv->dev);
int i, err = 0;
+ u32 reg;
/* initialize mdio bus */
priv->mii_bus = mdiobus_alloc();
if (!priv->mii_bus)
return -EIO;
+ if (of_machine_is_compatible("aspeed,ast2400") ||
+ of_machine_is_compatible("aspeed,ast2500")) {
+ /* This driver supports the old MDIO interface */
+ reg = ioread32(priv->base + FTGMAC100_OFFSET_REVR);
+ reg &= ~FTGMAC100_REVR_NEW_MDIO_INTERFACE;
+ iowrite32(reg, priv->base + FTGMAC100_OFFSET_REVR);
+ };
+
priv->mii_bus->name = "ftgmac100_mdio";
snprintf(priv->mii_bus->id, MII_BUS_ID_SIZE, "%s-%d",
pdev->name, pdev->id);
diff --git a/drivers/net/ethernet/faraday/ftgmac100.h b/drivers/net/ethernet/faraday/ftgmac100.h
index c258586ce4a4..8a377ab1d127 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.h
+++ b/drivers/net/ethernet/faraday/ftgmac100.h
@@ -134,6 +134,11 @@
#define FTGMAC100_DMAFIFOS_TXDMA_REQ (1 << 31)
/*
+ * Feature Register
+ */
+#define FTGMAC100_REVR_NEW_MDIO_INTERFACE BIT(31)
+
+/*
* Receive buffer size register
*/
#define FTGMAC100_RBSR_SIZE(x) ((x) & 0x3fff)
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 4/6] net/faraday: Clear stale interrupts
From: Joel Stanley @ 2016-09-21 23:05 UTC (permalink / raw)
To: davem; +Cc: clg, Gavin Shan, andrew, andrew, netdev, linux-kernel, benh
In-Reply-To: <20160921230503.23309-1-joel@jms.id.au>
From: Gavin Shan <gwshan@linux.vnet.ibm.com>
There is stale interrupt (PHYSTS_CHG in ISR, bit#6 in 0x0) from
the bootloader (uboot) when enabling the MAC. The stale interrupts
aren't part of kernel and should be cleared.
This clears the stale interrupts in ISR (0x0) when enabling the MAC.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 47f512224b57..189373743ddf 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1112,6 +1112,7 @@ static int ftgmac100_poll(struct napi_struct *napi, int budget)
static int ftgmac100_open(struct net_device *netdev)
{
struct ftgmac100 *priv = netdev_priv(netdev);
+ unsigned int status;
int err;
err = ftgmac100_alloc_buffers(priv);
@@ -1137,6 +1138,11 @@ static int ftgmac100_open(struct net_device *netdev)
ftgmac100_init_hw(priv);
ftgmac100_start_hw(priv, priv->use_ncsi ? 100 : 10);
+
+ /* Clear stale interrupts */
+ status = ioread32(priv->base + FTGMAC100_OFFSET_ISR);
+ iowrite32(status, priv->base + FTGMAC100_OFFSET_ISR);
+
if (netdev->phydev)
phy_start(netdev->phydev);
else if (priv->use_ncsi)
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 3/6] net/faraday: Adapt for Aspeed SoCs
From: Joel Stanley @ 2016-09-21 23:05 UTC (permalink / raw)
To: davem; +Cc: clg, gwshan, andrew, andrew, netdev, linux-kernel, benh
In-Reply-To: <20160921230503.23309-1-joel@jms.id.au>
The RXDES and TXDES registers bits in the ftgmac100 indicates EDO{R,T}R
at bit position 15 for the Faraday Tech IP. However, the version of this
IP present in the Aspeed SoCs has these bits at position 30 in the
registers.
It appers that ast2400 SoCs support both positions, with the 15th bit
marked as reserved but still functional. In the ast2500 this bit is
reused for another function, so we need a work around.
This was confirmed with engineers from Aspeed that using bit 30 is
correct for both the ast2400 and ast2500 SoCs.
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 62a88d1a1f99..47f512224b57 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -1345,9 +1345,6 @@ static int ftgmac100_probe(struct platform_device *pdev)
priv->netdev = netdev;
priv->dev = &pdev->dev;
- priv->rxdes0_edorr_mask = BIT(15);
- priv->txdes0_edotr_mask = BIT(15);
-
spin_lock_init(&priv->tx_lock);
/* initialize NAPI */
@@ -1381,6 +1378,16 @@ static int ftgmac100_probe(struct platform_device *pdev)
FTGMAC100_INT_PHYSTS_CHG |
FTGMAC100_INT_RPKT_BUF |
FTGMAC100_INT_NO_RXBUF);
+
+ if (of_machine_is_compatible("aspeed,ast2400") ||
+ of_machine_is_compatible("aspeed,ast2500")) {
+ priv->rxdes0_edorr_mask = BIT(30);
+ priv->txdes0_edotr_mask = BIT(30);
+ } else {
+ priv->rxdes0_edorr_mask = BIT(15);
+ priv->txdes0_edotr_mask = BIT(15);
+ }
+
if (pdev->dev.of_node &&
of_get_property(pdev->dev.of_node, "use-ncsi", NULL)) {
if (!IS_ENABLED(CONFIG_NET_NCSI)) {
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v2 1/6] net/faraday: Separate rx page storage from rxdesc
From: Joel Stanley @ 2016-09-21 23:04 UTC (permalink / raw)
To: davem; +Cc: clg, Andrew Jeffery, gwshan, andrew, netdev, linux-kernel, benh
In-Reply-To: <20160921230503.23309-1-joel@jms.id.au>
From: Andrew Jeffery <andrew@aj.id.au>
The ftgmac100 hardware revision in e.g. the Aspeed AST2500 no longer
reserves all bits in RXDES#2 but instead uses the bottom 16 bits to
store MAC frame metadata. Avoid corruption by shifting struct page
pointers out to their own member in struct ftgmac100.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
---
drivers/net/ethernet/faraday/ftgmac100.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/faraday/ftgmac100.c b/drivers/net/ethernet/faraday/ftgmac100.c
index 36361f8bf894..40622567159a 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -60,6 +60,8 @@ struct ftgmac100 {
struct ftgmac100_descs *descs;
dma_addr_t descs_dma_addr;
+ struct page *rx_pages[RX_QUEUE_ENTRIES];
+
unsigned int rx_pointer;
unsigned int tx_clean_pointer;
unsigned int tx_pointer;
@@ -341,18 +343,27 @@ static bool ftgmac100_rxdes_ipcs_err(struct ftgmac100_rxdes *rxdes)
return rxdes->rxdes1 & cpu_to_le32(FTGMAC100_RXDES1_IP_CHKSUM_ERR);
}
+static inline struct page **ftgmac100_rxdes_page_slot(struct ftgmac100 *priv,
+ struct ftgmac100_rxdes *rxdes)
+{
+ return &priv->rx_pages[rxdes - priv->descs->rxdes];
+}
+
/*
* rxdes2 is not used by hardware. We use it to keep track of page.
* Since hardware does not touch it, we can skip cpu_to_le32()/le32_to_cpu().
*/
-static void ftgmac100_rxdes_set_page(struct ftgmac100_rxdes *rxdes, struct page *page)
+static void ftgmac100_rxdes_set_page(struct ftgmac100 *priv,
+ struct ftgmac100_rxdes *rxdes,
+ struct page *page)
{
- rxdes->rxdes2 = (unsigned int)page;
+ *ftgmac100_rxdes_page_slot(priv, rxdes) = page;
}
-static struct page *ftgmac100_rxdes_get_page(struct ftgmac100_rxdes *rxdes)
+static struct page *ftgmac100_rxdes_get_page(struct ftgmac100 *priv,
+ struct ftgmac100_rxdes *rxdes)
{
- return (struct page *)rxdes->rxdes2;
+ return *ftgmac100_rxdes_page_slot(priv, rxdes);
}
/******************************************************************************
@@ -501,7 +512,7 @@ static bool ftgmac100_rx_packet(struct ftgmac100 *priv, int *processed)
do {
dma_addr_t map = ftgmac100_rxdes_get_dma_addr(rxdes);
- struct page *page = ftgmac100_rxdes_get_page(rxdes);
+ struct page *page = ftgmac100_rxdes_get_page(priv, rxdes);
unsigned int size;
dma_unmap_page(priv->dev, map, RX_BUF_SIZE, DMA_FROM_DEVICE);
@@ -779,7 +790,7 @@ static int ftgmac100_alloc_rx_page(struct ftgmac100 *priv,
return -ENOMEM;
}
- ftgmac100_rxdes_set_page(rxdes, page);
+ ftgmac100_rxdes_set_page(priv, rxdes, page);
ftgmac100_rxdes_set_dma_addr(rxdes, map);
ftgmac100_rxdes_set_dma_own(rxdes);
return 0;
@@ -791,7 +802,7 @@ static void ftgmac100_free_buffers(struct ftgmac100 *priv)
for (i = 0; i < RX_QUEUE_ENTRIES; i++) {
struct ftgmac100_rxdes *rxdes = &priv->descs->rxdes[i];
- struct page *page = ftgmac100_rxdes_get_page(rxdes);
+ struct page *page = ftgmac100_rxdes_get_page(priv, rxdes);
dma_addr_t map = ftgmac100_rxdes_get_dma_addr(rxdes);
if (!page)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH net-next 0/7] ftgmac100 support for ast2500
From: Joel Stanley @ 2016-09-21 23:04 UTC (permalink / raw)
To: davem
Cc: Cédric Le Goater, Gavin Shan, Andrew Lunn, Andrew Jeffery,
netdev, linux-kernel
In-Reply-To: <20160921230334.23224-1-joel@jms.id.au>
Please ignore this one.
On Thu, Sep 22, 2016 at 8:33 AM, Joel Stanley <joel@jms.id.au> wrote:
> Hello Dave,
>
> This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
> ast2500 SoCs. In particular, they ensure the driver works correctly on the
> ast2500 where the MAC block has seen some changes in register layout.
>
> They have been tested on ast2400 and ast2500 systems with the NCSI stack and
> with a directly attached PHY.
>
> Cheers,
>
> Joel
>
> Andrew Jeffery (2):
> net/ftgmac100: Separate rx page storage from rxdesc
> net/ftgmac100: Make EDO{R,T}R bits configurable
>
> Gavin Shan (2):
> net/faraday: Avoid PHYSTS_CHG interrupt
> net/faraday: Clear stale interrupts
>
> Joel Stanley (3):
> net/ftgmac100: Adapt for Aspeed SoCs
> net/faraday: Fix phy link irq on Aspeed G5 SoCs
> net/faraday: Configure old MDIO interface on Aspeed SoCs
>
> drivers/net/ethernet/faraday/ftgmac100.c | 92 ++++++++++++++++++++++++--------
> drivers/net/ethernet/faraday/ftgmac100.h | 8 ++-
> 2 files changed, 77 insertions(+), 23 deletions(-)
>
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH net-next 0/7] ftgmac100 support for ast2500
From: Joel Stanley @ 2016-09-21 23:03 UTC (permalink / raw)
To: davem; +Cc: clg, gwshan, andrew, andrew, netdev, linux-kernel
Hello Dave,
This series adds support to the ftgmac100 driver for the Aspeed ast2400 and
ast2500 SoCs. In particular, they ensure the driver works correctly on the
ast2500 where the MAC block has seen some changes in register layout.
They have been tested on ast2400 and ast2500 systems with the NCSI stack and
with a directly attached PHY.
Cheers,
Joel
Andrew Jeffery (2):
net/ftgmac100: Separate rx page storage from rxdesc
net/ftgmac100: Make EDO{R,T}R bits configurable
Gavin Shan (2):
net/faraday: Avoid PHYSTS_CHG interrupt
net/faraday: Clear stale interrupts
Joel Stanley (3):
net/ftgmac100: Adapt for Aspeed SoCs
net/faraday: Fix phy link irq on Aspeed G5 SoCs
net/faraday: Configure old MDIO interface on Aspeed SoCs
drivers/net/ethernet/faraday/ftgmac100.c | 92 ++++++++++++++++++++++++--------
drivers/net/ethernet/faraday/ftgmac100.h | 8 ++-
2 files changed, 77 insertions(+), 23 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs
From: Jeff Kirsher @ 2016-09-21 21:23 UTC (permalink / raw)
To: Or Gerlitz, Samudrala, Sridhar
Cc: David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane,
Ilya Lesokhin, Andy Gospodarek, John Fastabend, Jiri Pirko,
Rony Efraim
In-Reply-To: <CAJ3xEMj-teLmjg+Nzn0pHsnz8P=EY6uF4VzDJsxVEOTihStrLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2173 bytes --]
On Wed, 2016-09-21 at 22:21 +0300, Or Gerlitz wrote:
> On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
> > On 9/21/2016 12:04 AM, Or Gerlitz wrote:
>
>
> >> so what happens after this patchset is applied and before the future
> work is
> >> submitted? RX/TX slow path through the VFPRs isn't supported and what
> >> about fast path? in other words what happens when someone
> >> loads the driver, sets SRIOV (--> the driver set itself to switchdev
> mode
> >> and VFPRs are created) and then a VF sends a packet? do you still put
> >> into the HW the legacy DMAC based switching rules? I am not
> following...
>
> > The VF driver requests adding the dmac based filter rules via mailbox
> > messages to PF and that is not changed in this patchset.
> > Once we have VFPR TX/RX support, we will not allow the VF driver to add
> > these rules, Instead a host based
> > program will be able to add these rules to enable the fast path.
>
> I see, this means that when this patch set is applied your driver
> reports through devlink that they are in switchdev mode, but the
> operational state of the VFs and VFPRs isn't such - as the VFs dictate
> the steering and the VFPRs don't support slow path TX/RX --- in an
> earlier comment you made on this thread you said that you will be
> submitting RX/TX support in the next patchset. Maybe it would be best
> if you can take the VFPRs patches out of this series and roll a follow
> up series with all what's needed? unless you need more time and gonna
> miss 4.9 as of that... if the patches are ready, I say lets have them
> all in one series, if not, I wonder what other people think on the
> matter. I am basically half+ good to have also the half baked code
> base merged
>
> Anyway, there's no point to report through ethtool something (VF vport
> HW stats) you can report in the standard and convenient manner, so
> this one please do address regardless of the prev comment.
I will drop Sridhar's changes from this series for now, so that he can do
the re-work AND provide the additional patches he referred to earlier at a
later date.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] L2TP:Adjust intf MTU, add underlay L3, overlay L2
From: R. Parameswaran @ 2016-09-21 21:11 UTC (permalink / raw)
To: kleptog, jchapman, mostrows, acme, netdev
Cc: davem, linux-kernel, nprachan, rshearma, dfawcus, stephen
Take into account all of the tunnel encapsulation headers when setting
up the MTU on the L2TP logical interface device. Otherwise, packets
created by the applications on top of the L2TP layer are larger
than they ought to be, relative to the underlay MTU, leading to
needless fragmentation once the outer IP encap is added.
Specifically, take into account the (outer, underlay) IP header
imposed on the encapsulated L2TP packet, and the Layer 2 header
imposed on the inner IP packet prior to L2TP encapsulation.
Do not assume an Ethernet (non-jumbo) underlay. Use the PMTU mechanism
and the dst entry in the L2TP tunnel socket to directly pull up
the underlay MTU (as the baseline number on top of which the
encapsulation headers are factored in). Fall back to Ethernet MTU
if this fails.
Signed-off-by: Ramkumar Parameswaran <rparames@brocade.com>
Reviewed-by: N. Prachanda <nprachan@brocade.com>,
R. Shearman <rshearma@brocade.com>,
D. Fawcus <dfawcus@brocade.com>
---
net/l2tp/l2tp_eth.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 57fc5a4..dbcd6bd 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -30,6 +30,9 @@
#include <net/xfrm.h>
#include <net/net_namespace.h>
#include <net/netns/generic.h>
+#include <linux/ip.h>
+#include <linux/ipv6.h>
+#include <linux/udp.h>
#include "l2tp_core.h"
@@ -206,6 +209,46 @@ static void l2tp_eth_show(struct seq_file *m, void
*arg)
}
#endif
+static void l2tp_eth_adjust_mtu(struct l2tp_tunnel *tunnel,
+ struct l2tp_session *session,
+ struct net_device *dev)
+{
+ unsigned int overhead = 0;
+ struct dst_entry *dst;
+
+ if (session->mtu != 0) {
+ dev->mtu = session->mtu;
+ dev->needed_headroom += session->hdr_len;
+ if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+ dev->needed_headroom += sizeof(struct udphdr);
+ return;
+ }
+ overhead = session->hdr_len;
+ /* Adjust MTU, factor overhead - underlay L3 hdr, overlay L2 hdr*/
+ if (tunnel->sock->sk_family == AF_INET)
+ overhead += (ETH_HLEN + sizeof(struct iphdr));
+ else if (tunnel->sock->sk_family == AF_INET6)
+ overhead += (ETH_HLEN + sizeof(struct ipv6hdr));
+ /* Additionally, if the encap is UDP, account for UDP header size */
+ if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+ overhead += sizeof(struct udphdr);
+ /* If PMTU discovery was enabled, use discovered MTU on L2TP device */
+ dst = sk_dst_get(tunnel->sock);
+ if (dst) {
+ u32 pmtu = dst_mtu(dst);
+
+ if (pmtu != 0)
+ dev->mtu = pmtu;
+ dst_release(dst);
+ }
+ /* else (no PMTUD) L2TP dev MTU defaulted to Ethernet MTU in caller */
+ session->mtu = dev->mtu - overhead;
+ dev->mtu = session->mtu;
+ dev->needed_headroom += session->hdr_len;
+ if (tunnel->encap == L2TP_ENCAPTYPE_UDP)
+ dev->needed_headroom += sizeof(struct udphdr);
+}
+
static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32
session_id, u32 peer_session_id, struct l2tp_session_cfg *cfg)
{
struct net_device *dev;
@@ -255,11 +298,8 @@ static int l2tp_eth_create(struct net *net, u32
tunnel_id, u32 session_id, u32 p
}
dev_net_set(dev, net);
- if (session->mtu == 0)
- session->mtu = dev->mtu - session->hdr_len;
- dev->mtu = session->mtu;
- dev->needed_headroom += session->hdr_len;
+ l2tp_eth_adjust_mtu(tunnel, session, dev);
priv = netdev_priv(dev);
priv->dev = dev;
priv->session = session;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jesper Dangaard Brouer @ 2016-09-21 19:56 UTC (permalink / raw)
To: Tom Herbert
Cc: Thomas Graf, David S. Miller, Linux Kernel Network Developers,
Kernel Team, Tariq Toukan, Brenden Blanco, Alexei Starovoitov,
Eric Dumazet, brouer
In-Reply-To: <CALx6S36ZCdh5iOp6CPfztVKOEkDFgUo1RyqWMJVxhakOYNx8iw@mail.gmail.com>
On Wed, 21 Sep 2016 08:08:34 -0700 Tom Herbert <tom@herbertland.com> wrote:
> On Wed, Sep 21, 2016 at 7:48 AM, Thomas Graf <tgraf@suug.ch> wrote:
> > On 09/21/16 at 07:19am, Tom Herbert wrote:
> >> certain design that because of constraints on one kernel interface. As
> >> a kernel developer I want flexibility on how we design and implement
> >> things!
> >
> > Perfectly valid argument. I reviewed your ILA changes and did not
> > object to them.
> >
> >
> >> I think there are two questions that this patch set poses for the
> >> community wrt XDP:
> >>
> >> #1: Should we allow alternate code to run in XDP other than BPF?
> >> #2: If #1 is true what is the best way to implement that?
> >>
> >> If the answer to #1 is "no" then the answer to #2 is irrelevant. So
> >> with this RFC I'm hoping we can come the agreement on questions #1.
I vote yes to #1.
> > I'm not opposed to running non-BPF code at XDP. I'm against adding
> > a linked list of hook consumers.
I also worry about the performance impact of a linked list. We should
simple benchmark it instead of discussing it! ;-)
> > Would anyone require to run XDP-BPF in combination ILA? Or XDP-BPF
> > in combination with a potential XDP-nftables? We don't know yet I
> > guess.
> >
> Right. Admittedly, I feel like we owe a bit of reciprocity to
> nftables. For ILA we are using the NF_INET_PRE_ROUTING hook with our
> own code (looks like ipvlan set nfhooks as well). This works really
> well and saves the value of early demux in ILA. Had we not had the
> ability to use nfhooks in this fashion it's likely we would have had
> to create another hook (we did try putting translation in nftables
> rules but that was too inefficient for ILA).
Thinking about it, I actually think Tom is proposing a very valid user
of the XDP hook, which is the kernel itself. And Tom even have a real
first user ILA. The way I read the ILA-RFC-draft[1], the XDP hook
would benefit the NVE (Network Virtualization Edge) component, which
can run separately or run on the Tenant System, where the latter case
could use XDP_PASS.
[1] https://www.ietf.org/archive/id/draft-herbert-nvo3-ila-02.txt
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [RFC v2 07/12] qedr: Add support for memory registeration verbs
From: Sagi Grimberg @ 2016-09-21 19:53 UTC (permalink / raw)
To: Ram Amrani, davem, dledford
Cc: Ariel.Elior, Michal.Kalderon, Yuval.Mintz, rajesh.borundia,
linux-rdma, netdev
In-Reply-To: <1474367764-9555-8-git-send-email-Ram.Amrani@cavium.com>
> +static int qedr_set_page(struct ib_mr *ibmr, u64 addr)
> +{
> + struct qedr_mr *mr = get_qedr_mr(ibmr);
> + struct qedr_pbl *pbl_table;
> + struct regpair *pbe;
> + u32 pbes_in_page;
> +
> + if (unlikely(mr->npages == mr->info.pbl_info.num_pbes)) {
> + DP_ERR(mr->dev, "qedr_set_page failes when %d\n", mr->npages);
> + return -ENOMEM;
> + }
> +
> + DP_VERBOSE(mr->dev, QEDR_MSG_MR, "qedr_set_page pages[%d] = 0x%llx\n",
> + mr->npages, addr);
> +
> + pbes_in_page = mr->info.pbl_info.pbl_size / sizeof(u64);
> + pbl_table = mr->info.pbl_table + (mr->npages / pbes_in_page);
> + pbe = (struct regpair *)pbl_table->va;
> + pbe += mr->npages % pbes_in_page;
> + pbe->lo = cpu_to_le32((u32)addr);
> + pbe->hi = cpu_to_le32((u32)upper_32_bits(addr));
> +
> + mr->npages++;
> +
> + return 0;
> +}
Looks better.
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
^ permalink raw reply
* Re: [net-next 01/15] i40e: Introduce VF port representor/control netdevs
From: Or Gerlitz @ 2016-09-21 19:21 UTC (permalink / raw)
To: Samudrala, Sridhar
Cc: Jeff Kirsher, David Miller, Linux Netdev List, nhorman@redhat.com,
sassmann@redhat.com, jogreene@redhat.com, guru.anbalagane,
Ilya Lesokhin, Andy Gospodarek, John Fastabend, Jiri Pirko,
Rony Efraim
In-Reply-To: <57E2BC74.5040905@intel.com>
On Wed, Sep 21, 2016 at 7:59 PM, Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
> On 9/21/2016 12:04 AM, Or Gerlitz wrote:
>> so what happens after this patchset is applied and before the future work is
>> submitted? RX/TX slow path through the VFPRs isn't supported and what
>> about fast path? in other words what happens when someone
>> loads the driver, sets SRIOV (--> the driver set itself to switchdev mode
>> and VFPRs are created) and then a VF sends a packet? do you still put
>> into the HW the legacy DMAC based switching rules? I am not following...
> The VF driver requests adding the dmac based filter rules via mailbox
> messages to PF and that is not changed in this patchset.
> Once we have VFPR TX/RX support, we will not allow the VF driver to add
> these rules, Instead a host based
> program will be able to add these rules to enable the fast path.
I see, this means that when this patch set is applied your driver
reports through devlink that they are in switchdev mode, but the
operational state of the VFs and VFPRs isn't such - as the VFs dictate
the steering and the VFPRs don't support slow path TX/RX --- in an
earlier comment you made on this thread you said that you will be
submitting RX/TX support in the next patchset. Maybe it would be best
if you can take the VFPRs patches out of this series and roll a follow
up series with all what's needed? unless you need more time and gonna
miss 4.9 as of that... if the patches are ready, I say lets have them
all in one series, if not, I wonder what other people think on the
matter. I am basically half+ good to have also the half baked code
base merged
Anyway, there's no point to report through ethtool something (VF vport
HW stats) you can report in the standard and convenient manner, so
this one please do address regardless of the prev comment.
Or.
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Thomas Graf @ 2016-09-21 18:58 UTC (permalink / raw)
To: Tom Herbert
Cc: Jakub Kicinski, Alexei Starovoitov, David S. Miller,
Linux Kernel Network Developers, Kernel Team, Tariq Toukan,
Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <CALx6S34c6Mz=YpbiPcVNe38wTkxfjB9SWxaqtz1LivLeGzssRQ@mail.gmail.com>
On 09/21/16 at 11:50am, Tom Herbert wrote:
> 50 lines in one driver is not a big deal, 50 lines in a hundred
> drivers is! I learned this lesson in BQL which was well abstracted out
> to be minimally invasive but we still saw many issues because of the
> pecularities of different drivers.
You want to enable XDP in a hundred drivers? Are you planning to
deploy ISA NIC based ILA routers? ;-)
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jakub Kicinski @ 2016-09-21 18:54 UTC (permalink / raw)
To: Tom Herbert
Cc: Alexei Starovoitov, David S. Miller,
Linux Kernel Network Developers, Kernel Team, Tariq Toukan,
Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <CALx6S34c6Mz=YpbiPcVNe38wTkxfjB9SWxaqtz1LivLeGzssRQ@mail.gmail.com>
On Wed, 21 Sep 2016 11:50:06 -0700, Tom Herbert wrote:
> On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> > On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
> >> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> >> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
> >> >> > - Reduces the amount of code and complexity needed in drivers to
> >> >> > manage XDP
> >> >>
> >> >> hmm:
> >> >> 534 insertions(+), 144 deletions(-)
> >> >> looks like increase in complexity instead.
> >> >
> >> > and more to come to tie this with HW offloads.
> >>
> >> The amount of driver code did decrease with these patches:
> >>
> >> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 64 ++++----------------------
> >> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 25 ++++------
> >> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
> >>
> >> Minimizing complexity being added to drivers for XDP is critical since
> >> we basically asking every driver to replicate the function. This
> >> property also should also apply to HW offloads, the more complexity we
> >> can abstract out drivers into a common backend infrastructure the
> >> better for supporting across different drivers.
> >
> > I'm in the middle of writing/testing XDP support for the Netronome's
> > driver and generic infra is very much appreciated ;) In my experience
> > the 50 lines of code which are required for assigning the programs and
> > freeing them aren't really a big deal, though.
> >
>
> 50 lines in one driver is not a big deal, 50 lines in a hundred
> drivers is! I learned this lesson in BQL which was well abstracted out
> to be minimally invasive but we still saw many issues because of the
> pecularities of different drivers.
Agreed, I just meant to say that splitting rings and rewritting RX path
to behave differently for XDP vs non-XDP case is way more brain
consuming than a bit of boilerplate code so if anyone could solve those
two it would be much appreciated :) My main point was what I wrote
below, though.
> > Let's also separate putting xdp_prog in netdevice/napi_struct from the
> > generic hook infra. All the simplifications to the driver AFAICS come
> > from the former. If everyone is fine with growing napi_struct we can do
> > that but IMHO this is not an argument for the generic infra :)
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Tom Herbert @ 2016-09-21 18:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, David S. Miller,
Linux Kernel Network Developers, Kernel Team, Tariq Toukan,
Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <20160921194548.33b85cb3@jkicinski-Precision-T1700>
On Wed, Sep 21, 2016 at 11:45 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
>> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
>> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
>> >> > - Reduces the amount of code and complexity needed in drivers to
>> >> > manage XDP
>> >>
>> >> hmm:
>> >> 534 insertions(+), 144 deletions(-)
>> >> looks like increase in complexity instead.
>> >
>> > and more to come to tie this with HW offloads.
>>
>> The amount of driver code did decrease with these patches:
>>
>> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 64 ++++----------------------
>> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 25 ++++------
>> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
>>
>> Minimizing complexity being added to drivers for XDP is critical since
>> we basically asking every driver to replicate the function. This
>> property also should also apply to HW offloads, the more complexity we
>> can abstract out drivers into a common backend infrastructure the
>> better for supporting across different drivers.
>
> I'm in the middle of writing/testing XDP support for the Netronome's
> driver and generic infra is very much appreciated ;) In my experience
> the 50 lines of code which are required for assigning the programs and
> freeing them aren't really a big deal, though.
>
50 lines in one driver is not a big deal, 50 lines in a hundred
drivers is! I learned this lesson in BQL which was well abstracted out
to be minimally invasive but we still saw many issues because of the
pecularities of different drivers.
> Let's also separate putting xdp_prog in netdevice/napi_struct from the
> generic hook infra. All the simplifications to the driver AFAICS come
> from the former. If everyone is fine with growing napi_struct we can do
> that but IMHO this is not an argument for the generic infra :)
^ permalink raw reply
* Re: [PATCH v6 5/6] net: ipv4, ipv6: run cgroup eBPF egress programs
From: Thomas Graf @ 2016-09-21 18:48 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Daniel Mack, htejun, daniel, ast, davem, kafai, fw, harald,
netdev, sargun, cgroups
In-Reply-To: <20160921154533.GA13656@salvia>
On 09/21/16 at 05:45pm, Pablo Neira Ayuso wrote:
> On Tue, Sep 20, 2016 at 06:43:35PM +0200, Daniel Mack wrote:
> > The point is that from an application's perspective, restricting the
> > ability to bind a port and dropping packets that are being sent is a
> > very different thing. Applications will start to behave differently if
> > they can't bind to a port, and that's something we do not want to happen.
>
> What is exactly the problem? Applications are not checking for return
> value from bind? They should be fixed. If you want to collect
> statistics, I see no reason why you couldn't collect them for every
> EACCESS on each bind() call.
It's not about applications not checking the return value of bind().
Unfortunately, many applications (or the respective libraries they use)
retry on connect() failure but handle bind() errors as a hard failure
and exit. Yes, it's an application or library bug but these
applications have very specific exceptions how something fails.
Sometimes even going from drop to RST will break applications.
Paranoia speaking: by returning errors where no error was returned
before, undefined behaviour occurs. In Murphy speak: things break.
This is given and we can't fix it from the kernel side. Returning at
system call level has many benefits but it's not always an option.
Adding the late hook does not prevent filtering at socket layer to
also be added. I think we need both.
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Jakub Kicinski @ 2016-09-21 18:45 UTC (permalink / raw)
To: Tom Herbert
Cc: Alexei Starovoitov, David S. Miller,
Linux Kernel Network Developers, Kernel Team, Tariq Toukan,
Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <CALx6S37CkP44ZSNZM3UNBMv_ECFS6tf5T_37VSMyBCjm9ejiDw@mail.gmail.com>
On Wed, 21 Sep 2016 10:39:40 -0700, Tom Herbert wrote:
> On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> > On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
> >> > - Reduces the amount of code and complexity needed in drivers to
> >> > manage XDP
> >>
> >> hmm:
> >> 534 insertions(+), 144 deletions(-)
> >> looks like increase in complexity instead.
> >
> > and more to come to tie this with HW offloads.
>
> The amount of driver code did decrease with these patches:
>
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 64 ++++----------------------
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 25 ++++------
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
>
> Minimizing complexity being added to drivers for XDP is critical since
> we basically asking every driver to replicate the function. This
> property also should also apply to HW offloads, the more complexity we
> can abstract out drivers into a common backend infrastructure the
> better for supporting across different drivers.
I'm in the middle of writing/testing XDP support for the Netronome's
driver and generic infra is very much appreciated ;) In my experience
the 50 lines of code which are required for assigning the programs and
freeing them aren't really a big deal, though.
Let's also separate putting xdp_prog in netdevice/napi_struct from the
generic hook infra. All the simplifications to the driver AFAICS come
from the former. If everyone is fine with growing napi_struct we can do
that but IMHO this is not an argument for the generic infra :)
^ permalink raw reply
* [PATCH v2] tcp: fix wrong checksum calculation on MTU probing
From: Douglas Caetano dos Santos @ 2016-09-21 18:26 UTC (permalink / raw)
To: David Miller; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <20160920.225729.1715125475365382873.davem@davemloft.net>
With TCP MTU probing enabled and offload TX checksumming disabled,
tcp_mtu_probe() calculated the wrong checksum when a fragment being copied
into the probe's SKB had an odd length. This was caused by the direct use
of skb_copy_and_csum_bits() to calculate the checksum, as it pads the
fragment being copied, if needed. When this fragment was not the last, a
subsequent call used the previous checksum without considering this
padding.
The effect was a stale connection in one way, as even retransmissions
wouldn't solve the problem, because the checksum was never recalculated for
the full SKB length.
Signed-off-by: Douglas Caetano dos Santos <douglascs@taghos.com.br>
---
net/ipv4/tcp_output.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index f53d0cc..767135e 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1968,10 +1968,12 @@ static int tcp_mtu_probe(struct sock *sk)
copy = min_t(int, skb->len, probe_size - len);
if (nskb->ip_summed)
skb_copy_bits(skb, 0, skb_put(nskb, copy), copy);
- else
- nskb->csum = skb_copy_and_csum_bits(skb, 0,
- skb_put(nskb, copy),
- copy, nskb->csum);
+ else {
+ __wsum csum = skb_copy_and_csum_bits(skb, 0,
+ skb_put(nskb, copy),
+ copy, 0);
+ nskb->csum = csum_block_add(nskb->csum, csum, len);
+ }
if (skb->len <= copy) {
/* We've eaten all the data from this skb.
--
2.5.0
^ permalink raw reply related
* Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show
From: Marcelo @ 2016-09-21 18:24 UTC (permalink / raw)
To: hejianet
Cc: netdev, linux-sctp, linux-kernel, davem, Alexey Kuznetsov,
James Morris, Hideaki YOSHIFUJI, Patrick McHardy, Vlad Yasevich,
Neil Horman, Steffen Klassert, Herbert Xu
In-Reply-To: <84aae301-0d00-d953-e6f6-d2d163d1136a@gmail.com>
On Thu, Sep 22, 2016 at 12:18:46AM +0800, hejianet wrote:
> Hi Marcelo
>
> sorry for the late, just came back from a vacation.
Hi, no problem. Hope your batteries are recharged now :-)
>
> On 9/14/16 7:55 PM, Marcelo wrote:
> > Hi Jia,
> >
> > On Wed, Sep 14, 2016 at 01:58:42PM +0800, hejianet wrote:
> > > Hi Marcelo
> > >
> > >
> > > On 9/13/16 2:57 AM, Marcelo wrote:
> > > > On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
> > > > > This is to use the generic interface snmp_get_cpu_field{,64}_batch to
> > > > > aggregate the data by going through all the items of each cpu sequentially.
> > > > > Then snmp_seq_show and netstat_seq_show are split into 2 parts to avoid build
> > > > > warning "the frame size" larger than 1024 on s390.
> > > > Yeah about that, did you test it with stack overflow detection?
> > > > These arrays can be quite large.
> > > >
> > > > One more below..
> > > Do you think it is acceptable if the stack usage is a little larger than 1024?
> > > e.g. 1120
> > > I can't find any other way to reduce the stack usage except use "static" before
> > > unsigned long buff[TCP_MIB_MAX]
> > >
> > > PS. sizeof buff is about TCP_MIB_MAX(116)*8=928
> > > B.R.
> > That's pretty much the question. Linux has the option on some archs to
> > run with 4Kb (4KSTACKS option), so this function alone would be using
> > 25% of it in this last case. While on x86_64, it uses 16Kb (6538b8ea886e
> > ("x86_64: expand kernel stack to 16K")).
> >
> > Adding static to it is not an option as it actually makes the variable
> > shared amongst the CPUs (and then you have concurrency issues), plus the
> > fact that it's always allocated, even while not in use.
> >
> > Others here certainly know better than me if it's okay to make such
> > usage of the stach.
> What about this patch instead?
> It is a trade-off. I split the aggregation process into 2 parts, it will
> increase the cache miss a little bit, but it can reduce the stack usage.
> After this, stack usage is 672bytes
> objdump -d vmlinux | ./scripts/checkstack.pl ppc64 | grep seq_show
> 0xc0000000007f7cc0 netstat_seq_show_tcpext.isra.3 [vmlinux]:672
>
> diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
> index c6ee8a2..cc41590 100644
> --- a/net/ipv4/proc.c
> +++ b/net/ipv4/proc.c
> @@ -486,22 +486,37 @@ static const struct file_operations snmp_seq_fops = {
> */
> static int netstat_seq_show_tcpext(struct seq_file *seq, void *v)
> {
> - int i;
> - unsigned long buff[LINUX_MIB_MAX];
> + int i, c;
> + unsigned long buff[LINUX_MIB_MAX/2 + 1];
> struct net *net = seq->private;
>
> - memset(buff, 0, sizeof(unsigned long) * LINUX_MIB_MAX);
> + memset(buff, 0, sizeof(unsigned long) * (LINUX_MIB_MAX/2 + 1));
>
> seq_puts(seq, "TcpExt:");
> for (i = 0; snmp4_net_list[i].name; i++)
> seq_printf(seq, " %s", snmp4_net_list[i].name);
>
> seq_puts(seq, "\nTcpExt:");
> - snmp_get_cpu_field_batch(buff, snmp4_net_list,
> - net->mib.net_statistics);
> - for (i = 0; snmp4_net_list[i].name; i++)
> + for_each_possible_cpu(c) {
> + for (i = 0; i < LINUX_MIB_MAX/2; i++)
> + buff[i] += snmp_get_cpu_field(
> + net->mib.net_statistics,
> + c, snmp4_net_list[i].entry);
> + }
> + for (i = 0; i < LINUX_MIB_MAX/2; i++)
> seq_printf(seq, " %lu", buff[i]);
>
> + memset(buff, 0, sizeof(unsigned long) * (LINUX_MIB_MAX/2 + 1));
> + for_each_possible_cpu(c) {
> + for (i = LINUX_MIB_MAX/2; snmp4_net_list[i].name; i++)
> + buff[i - LINUX_MIB_MAX/2] += snmp_get_cpu_field(
> + net->mib.net_statistics,
> + c,
> + snmp4_net_list[i].entry);
> + }
> + for (i = LINUX_MIB_MAX/2; snmp4_net_list[i].name; i++)
> + seq_printf(seq, " %lu", buff[i - LINUX_MIB_MAX/2]);
> +
> return 0;
> }
Yep, it halves the stack usage, but it doesn't look good heh
But well, you may try to post the patchset (with or without this last
change, you pick) officially and see how it goes. As you're posting as
RFC, it's not being evaluated as seriously.
FWIW, I tested your patches, using your test and /proc/net/snmp file on
a x86_64 box, Intel(R) Xeon(R) CPU E5-2643 v3.
Before the patches:
Performance counter stats for './test /proc/net/snmp':
5.225 cache-misses
12.708.673.785 L1-dcache-loads
1.288.450.174 L1-dcache-load-misses # 10,14% of all L1-dcache hits
1.271.857.028 LLC-loads
4.122 LLC-load-misses # 0,00% of all LL-cache hits
9,174936524 seconds time elapsed
After:
Performance counter stats for './test /proc/net/snmp':
2.865 cache-misses
30.203.883.807 L1-dcache-loads
1.215.774.643 L1-dcache-load-misses # 4,03% of all L1-dcache hits
1.181.662.831 LLC-loads
2.685 LLC-load-misses # 0,00% of all LL-cache hits
13,374445056 seconds time elapsed
Numbers were steady across multiple runs.
Marcelo
>
> > > > > +static int netstat_seq_show_ipext(struct seq_file *seq, void *v)
> > > > > +{
> > > > > + int i;
> > > > > + u64 buff64[IPSTATS_MIB_MAX];
> > > > > + struct net *net = seq->private;
> > > > > seq_puts(seq, "\nIpExt:");
> > > > > for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
> > > > > seq_printf(seq, " %s", snmp4_ipextstats_list[i].name);
> > > > > seq_puts(seq, "\nIpExt:");
> > > > You're missing a memset() call here.
> > Not sure if you missed this one or not..
> indeed, thanks
> B.R.
> Jia
> > Thanks,
> > Marcelo
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [ANNOUNCE] ndiv: line-rate network traffic processing
From: Willy Tarreau @ 2016-09-21 18:06 UTC (permalink / raw)
To: Tom Herbert; +Cc: Linux Kernel Network Developers
In-Reply-To: <CALx6S34Oy6QeOxR45PuuX70hfm-TR=2mpDwwqr82c7tvpWLX+Q@mail.gmail.com>
Hi Tom,
On Wed, Sep 21, 2016 at 10:16:45AM -0700, Tom Herbert wrote:
> This does seem interesting and indeed the driver datapath looks very
> much like XDP. It would be quite interesting if you could rebase and
> then maybe look at how this can work with XDP that would be helpful.
OK I'll assign some time to rebase it then.
> The return actions are identical,
I'm not surprized that the same needs lead to the same designs when
these designs are constrained by CPU cycle count :-)
> but processing descriptor meta data
> (like checksum, vlan) is not yet implemented in XDP-- maybe this is
> something we can leverage from ndiv?
Yes possibly. It's not a big work but it's absolutely mandatory if you
don't want to waste some smart devices' valuable performance improvements.
We changed our API when porting it to ixgbe to support what this NIC (and
many other ones) supports so that the application code doesn't have to
deal with checksums etc. By the way, VLAN is not yet implemented in the
mvneta driver. But this choice ensures that no application has to deal
nor to create bugs.
Cheers,
Willy
^ permalink raw reply
* Re: [ANNOUNCE] ndiv: line-rate network traffic processing
From: Willy Tarreau @ 2016-09-21 18:00 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Tom Herbert, Alexei Starovoitov, Brenden Blanco,
Tariq Toukan
In-Reply-To: <20160921182639.2fce960a@redhat.com>
Hi Jesper!
On Wed, Sep 21, 2016 at 06:26:39PM +0200, Jesper Dangaard Brouer wrote:
> I definitely want to study it!
Great, at least I've not put this online for nothing :-)
> You mention XDP. If you didn't notice, I've created some documentation
> on XDP (it is very "live" documentation at this point and it will
> hopefully "materialized" later in the process). But it should be a good
> starting point for understanding XDP:
>
> https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html
Thanks, I'll read it. We'll need to educate ourselves to see how to port
our anti-ddos to XDP in the future I guess, so better ensure the design
is fit from the beginning!
> > I presented it in 2014 at kernel recipes :
> > http://kernel-recipes.org/en/2014/ndiv-a-low-overhead-network-traffic-diverter/
>
> Cool, and it even have a video!
Yep, with a horrible english accent :-)
> > It now supports drivers mvneta, ixgbe, e1000e, e1000 and igb. It is
> > very light, and retrieves the packets in the NIC's driver before they
> > are converted to an skb, then submits them to a registered RX handler
> > running in softirq context so we have the best of all worlds by
> > benefitting from CPU scalability, delayed processing, and not paying
> > the cost of switching to userland. Also an rx_done() function allows
> > handlers to batch their processing.
>
> Wow - it does sound a lot like XDP! I would say that is sort of
> validate the current direction of XDP, and that there are real
> use-cases for this stuff.
Absolutely! In fact what drove use to this architecture is that we first
wrote our anti-ddos in userland using netmap. While userland might be OK
for switches and routers, in our case we have haproxy listening on TCP
sockets and waiting for these packets. So the packets were bouncing from
kernel to user, then to kernel again, losing checksums, GRO, GSO, etc...
We modified it to support all of these but the performance was still poor,
capping at about 8 Gbps of forwarded traffic instead of ~40. Thus we thought
that the processing would definitely need to be placed in the kernel to avoid
this bouncing, and to avoid turning rings into newer rings all the time.
That's when I realized that it could possibly also cover my needs for a
sniffer and we redesigned the initial code to support both use cases. Now
we don't even see it in regular traffic, which is pretty nice.
> > The RX handler returns an action
> > among accepting the packet as-is, accepting it modified (eg: vlan or
> > tunnel decapsulation), dropping it, postponing the processing
> > (equivalent to EAGAIN), or building a new packet to send back.
>
> I'll be very interested in studying in-details how you implemented and
> choose what actions to implement.
OK. The HTTP server is a good use case to study because it lets packets
pass through, being dropped, or being responded to, and the code is very
small, so easy to analyse.
> What was the need for postponing the processing (EAGAIN)?
Our SYN cookie generator. If the NIC's Tx queue is full and we cannot build
a SYN-ACK, we prefer to break out of the Rx loop because there's still room
in the Rx ring (statistically speaking).
> > This last function is the one requiring the most changes in existing
> > drivers, but offers the widest range of possibilities. We use it to
> > send SYN cookies, but I have also implemented a stateless HTTP server
> > supporting keep-alive using it, achieving line-rate traffic processing
> > on a single CPU core when the NIC supports it. It's very convenient to
> > test various stateful TCP components as it's easy to sustain millions
> > of connections per second on it.
>
> Interesting, and controversial use-case. One controversial use-case
> for XDP, that I imagine was implementing a DNS accelerator, what
> answers simple and frequent requests.
We thought about such a use case as well, just like of a ping responder
(rate limited to avoid serving as DDoS responders).
> You took it a step further with a HTTP server!
It's a fake HTTP server. You ask it to return 1kB of data and it sends you
1kB. It can even do multiple segments but then you're facing the risk of
losses that you'd preferably avoid. But in our case it's very useful to
test various things including netfilter, LVS and haproxy because it
consumes so little power to reach performance levels that they cannot even
reach that you can set it up on a small machine (eg: a cheap USB-powered
ARM board saturates the GigE link with 340 kcps, 663 krps). However I found
that it *could* be fun to improve it to deliver favicons or small error
pages.
> > It does not support forwarding between NICs. It was my first goal
> > because I wanted to implement a TAP with it, bridging the traffic
> > between two ports, but figured it was adding some complexity to the
> > system back then.
>
> With all the XDP features at the moment, we have avoided going through
> the page allocator, by relying on different page recycling tricks.
>
> When doing forwarding between NICs is it harder to do these page
> recycling tricks. I've measured that page allocators fast-path
> ("recycling" same page) cost approx 270 cycles, and the 14Mpps cycle
> count on this 4GHz CPU is 268 cycles. Thus, it is a non-starter...
Wow indeed. We're doing complete stateful inspection and policy-based
filtering on less than 67 ns, so indeed here it would be far too long.
> Did you have to modify the page allocator?
> Or implement some kind of recycling?
We "simply" implemented our own Tx ring, depending on what drivers and
hardware support. This is the most complicated part of the code because
it is very hardware-dependant and because you want to deal with conflicts
between the packets being generated on the Rx path and other packets being
delivered by other cores on the regular Tx path. In some drivers we cheat
on the skb pointer in the descriptors, we set bit 0 to 1 to mark it as
being ours so that we recycle it into our ring after it's sent instead of
releasing an skb. That's why it would be hard to implement forwarding. I
thought that I could at least implement it between two NICs making use of
the same driver, but it could lead to starvation of certain tx rings and
other ones filling up. However I don't have a solution for now because I
decided to stop thinking about it at the moment. Over the long term I
would love to see my mirabox being used as an inline tap logging to USB3 :-)
Another important design choice that comes to my mind is that we purposely
decide to support optimal devices. We decided this after seeing how netmap
uses only the least common denominator between all supportable NICs
resulting in any NIC to become dumb. In our case, the driver has to feed
the checksum status, L3/L4 protocol types etc. If the NIC is too dumb to
support this, it just has to be implemented in software for this NIC only.
And in practice all NICs that matter support L3/L4 protocol identification
as well as checksum verification/computation, so it's not a problem and
the hardware continues to work for us for free.
> > However since then we've implemented traffic
> > capture in our product, exploiting this framework to capture without
> > losses at 14 Mpps. I may find some time to try to extract it later.
> > It uses the /sys API so that you can simply plug tcpdump -r on a
> > file there, though there's also an mmap version which uses less CPU
> > (that's important at 10G).
>
> Interesting. I do see a XDP use-case for RAW packet capture, but I've
> postponed that work until later. I would interested in how you solved
> it? E.g. Do you support zero-copy?
No, we intentionally copy. In fact on xeon processors, the memory bandwidth
is so huge that you don't even notice the copy. And by using small buffers,
you can even ensure that the memory blocks stays in L3 cache. We had most
difficulties with the /sys API because it only supports page-size transfers
and uses lots of CPU just for this, hence we had to implement mmap support
to present the packets to user-space (without copy here). But even the
regular /sys API with a double copy supports line-rate with high CPU usage.
I'll ask my coworker Emeric who did the sniffer if he can take it out as a
standalone component. It will take a bit of time because we're moving to a
new office and that significantly mangles our priorities as you can expect,
but that's definitely something we'd like to do.
> > In its current form since the initial code's intent was to limit
> > core changes, it happens not to modify anything in the kernel by
> > default and to reuse the net_device's ax25_ptr to attach devices
> > (idea borrowed from netmap), so it can be used on an existing
> > kernel just by loading the patched network drivers (yes, I know
> > it's not a valid solution for the long term).
> >
> > The current code is available here :
> >
> > http://git.kernel.org/cgit/linux/kernel/git/wtarreau/ndiv.git/
>
> I was just about to complain that the link was broken... but it fixed
> itself while writing this email ;-)
I noticed the same thing a few times already, and whatever I do, the
description is not updated. I suspect there's some load balancing with
one server not being updated as fast as the other ones.
> Can you instead explain what branch to look at?
Sure! For the most up-to-date code, better use ndiv_v5-4.4. It contains
the core (a single .h file), and support for ixgbe, e1000e, e1000, igb,
and the dummy HTTP server (slhttpd). For a more readable version, better
use ndiv_v5-3.14 which also contains the mvneta driver, it's much simpler
than the other ones and makes the code more readable. I'll have to port
it to 4.4 soon but didn't have time yet. We don't support mlx4 yet, and
it's a chicken-and-egg problem : by lack of time we don't work on porting
it and since we don't support it we don't use it in our products. That's
too bad because from what I've been told we should be able to reach high
packet rates there as well.
> > Please let me know if there could be some interest in rebasing it
> > on more recent versions (currently 3.10, 3.14 and 4.4 are supported).
>
> What, no support for 2.4 ;-)
Not yet :-) Jokes aside, given that the API is very simple, it could be
done if anyone needed, as it really doesn't rely on any existing
infrastructure. The API is reasonably OS-agnostic as it only wants
pointers and lengths. For sniffing and/or filtering on Rx/Tx paths
only, the code basically only is (synthetic code, just to illustrate) :
ndiv = netdev_get_ndiv(dev);
if (ndiv) {
ret = ndiv->handle_rx(ndiv, l3ptr, l3len, l2len, l2ptr, NULL);
if (ret & NDIV_RX_R_F_DROP)
continue;
}
Best regards,
Willy
^ permalink raw reply
* RE: [PATCH] net: fec: set mac address unconditionally
From: Andy Duan @ 2016-09-21 16:26 UTC (permalink / raw)
To: Gavin Schenk; +Cc: netdev@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <1474464655-126940-1-git-send-email-g.schenk@eckelmann.de>
From: Gavin Schenk <g.schenk@eckelmann.de> Sent: Wednesday, September 21, 2016 9:31 PM
> To: Andy Duan <fugang.duan@nxp.com>
> Cc: netdev@vger.kernel.org; kernel@pengutronix.de; Gavin Schenk
> <g.schenk@eckelmann.de>
> Subject: [PATCH] net: fec: set mac address unconditionally
>
> Fixes: 9638d19e4816 ("net: fec: add netif status check before set mac
> address")
>
> If the mac address origin is not dt, you can only safe assign a mac address
> after "link up" of the device. If the link is down the clocks are disabled and
> because of issues assigning registers when clocks are down the new mac
> address is discarded on some soc's. This fix sets the mac address
> unconditionally in fec_restart(...) and ensures consistens between fec
> registers and the network layer.
>
> Signed-off-by: Gavin Schenk <g.schenk@eckelmann.de>
> ---
It make sense, thanks.
Acked-by: Fugang Duan <fugang.duan@nxp.com>
> drivers/net/ethernet/freescale/fec_main.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index 2a03857cca18..bdabea6cd981 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -903,13 +903,11 @@ fec_restart(struct net_device *ndev)
> * enet-mac reset will reset mac address registers too,
> * so need to reconfigure it.
> */
> - if (fep->quirks & FEC_QUIRK_ENET_MAC) {
> - memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);
> - writel((__force u32)cpu_to_be32(temp_mac[0]),
> - fep->hwp + FEC_ADDR_LOW);
> - writel((__force u32)cpu_to_be32(temp_mac[1]),
> - fep->hwp + FEC_ADDR_HIGH);
> - }
> + memcpy(&temp_mac, ndev->dev_addr, ETH_ALEN);
> + writel((__force u32)cpu_to_be32(temp_mac[0]),
> + fep->hwp + FEC_ADDR_LOW);
> + writel((__force u32)cpu_to_be32(temp_mac[1]),
> + fep->hwp + FEC_ADDR_HIGH);
>
> /* Clear any outstanding interrupt. */
> writel(0xffffffff, fep->hwp + FEC_IEVENT);
> --
> 1.9.1
>
>
> Eckelmann AG
> Vorstand: Dipl.-Ing. Peter Frankenbach (Sprecher) Dipl.-Wi.-Ing. Philipp
> Eckelmann
> Dr.-Ing. Frank-Thomas Mellert Dr.-Ing. Marco Münchhof Dr.-Ing. Frank
> Uhlemann
> Vorsitzender des Aufsichtsrats: Hubertus G. Krossa
> Sitz der Gesellschaft: Berliner Str. 161, 65205 Wiesbaden, Amtsgericht
> Wiesbaden HRB 12636
> http://www.eckelmann.de
^ permalink raw reply
* Re: [PATCH RFC 1/3] xdp: Infrastructure to generalize XDP
From: Tom Herbert @ 2016-09-21 17:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Alexei Starovoitov, David S. Miller,
Linux Kernel Network Developers, Kernel Team, Tariq Toukan,
Brenden Blanco, Alexei Starovoitov, Eric Dumazet,
Jesper Dangaard Brouer
In-Reply-To: <20160921182657.67681e67@jkicinski-Precision-T1700>
On Wed, Sep 21, 2016 at 10:26 AM, Jakub Kicinski <kubakici@wp.pl> wrote:
> On Tue, 20 Sep 2016 17:01:39 -0700, Alexei Starovoitov wrote:
>> > - Reduces the amount of code and complexity needed in drivers to
>> > manage XDP
>>
>> hmm:
>> 534 insertions(+), 144 deletions(-)
>> looks like increase in complexity instead.
>
> and more to come to tie this with HW offloads.
The amount of driver code did decrease with these patches:
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 64 ++++----------------------
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 25 ++++------
drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 -
Minimizing complexity being added to drivers for XDP is critical since
we basically asking every driver to replicate the function. This
property also should also apply to HW offloads, the more complexity we
can abstract out drivers into a common backend infrastructure the
better for supporting across different drivers.
Tom
^ permalink raw reply
* As-salam o Alaikum
From: Saidat Abdulmumuni @ 2016-09-21 17:32 UTC (permalink / raw)
Hello, I am Saidat, I sent you a message yesterday, Please did you
receive it? Thank you!
^ 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;
as well as URLs for NNTP newsgroup(s).