* [PATCH] mvneta driver XDP fixes armhf
@ 2020-01-22 10:05 Sven Auhagen
2020-01-22 22:57 ` lorenzo.bianconi
0 siblings, 1 reply; 8+ messages in thread
From: Sven Auhagen @ 2020-01-22 10:05 UTC (permalink / raw)
To: netdev
Cc: lorenzo.bianconi, davem, thomas.petazzoni, brouer,
ilias.apalodimas, matteo.croce, mw, jakub.kicinski
Recently XDP Support was added to the mvneta driver for software buffer management.
I tested XDP with my armada 388 board. It has hardware buffer management defined in the device tree file.
I disabled the mvneta_bm module to test XDP.
I found multiple problems.
1. With hardware buffer management enabled and mvneta_bm disabled the rx_offset was set to 0 with armhf (32 bit) which leads to no headroom in XDP and therefore the XDP Redirect did not work.
2. Removing the hardware buffer management from the device tree file completely made the mvneta driver unusable as it did not work anymore.
After some debugging I found out that xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; has to be xdp->data = data + pp->rx_offset_correction; if pp->rx_offset_correction > 0.
I am not sure why and I am looking for help if someone is seeing the same on an arm64 board.
Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only.
Any feedback is appreciated.
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
--- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000
+++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000
@@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port
prefetch(data);
xdp->data_hard_start = data;
-xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE;
+xdp->data = data + pp->rx_offset_correction;
xdp->data_end = xdp->data + data_len;
xdp_set_data_meta_invalid(xdp);
@@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_
* NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
* platforms and 0B for 32-bit ones.
*/
-pp->rx_offset_correction = max(0,
+if (pp->bm_priv)
+pp->rx_offset_correction = max(0,
NET_SKB_PAD -
MVNETA_RX_PKT_OFFSET_CORRECTION);
}
+++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++
Beste Grüße/Best regards
Sven Auhagen
Dipl. Math. oec., M.Sc.
Voleatech GmbH
HRB: B 754643
USTID: DE303643180
Grathwohlstr. 5
72762 Reutlingen
Tel: +49 7121539550
Fax: +49 7121539551
E-Mail: sven.auhagen@voleatech.de
www.voleatech.de<https://www.voleatech.de>
Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-22 10:05 [PATCH] mvneta driver XDP fixes armhf Sven Auhagen @ 2020-01-22 22:57 ` lorenzo.bianconi 2020-01-24 12:03 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: lorenzo.bianconi @ 2020-01-22 22:57 UTC (permalink / raw) To: Sven Auhagen Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski [-- Attachment #1: Type: text/plain, Size: 3513 bytes --] Hi Sven, > Recently XDP Support was added to the mvneta driver for software buffer management. > I tested XDP with my armada 388 board. It has hardware buffer management defined in the device tree file. > I disabled the mvneta_bm module to test XDP. > > I found multiple problems. > > 1. With hardware buffer management enabled and mvneta_bm disabled the rx_offset was set to 0 with armhf (32 bit) which leads to no headroom in XDP and therefore the XDP Redirect did not work. > 2. Removing the hardware buffer management from the device tree file completely made the mvneta driver unusable as it did not work anymore. Do you mean removing 'buffer-manager' property from the device tree? > > After some debugging I found out that xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; has to be xdp->data = data + pp->rx_offset_correction; if pp->rx_offset_correction > 0. > I am not sure why and I am looking for help if someone is seeing the same on an arm64 board. Are you sure the hw does not insert the mvneta header before the data? It seems to me that it is added even for hw buffer devices (according to the code). > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > Any feedback is appreciated. > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > prefetch(data); > > xdp->data_hard_start = data; > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > +xdp->data = data + pp->rx_offset_correction; This will break XDP support for 'real' sw buffer devices like Espressobin. Regards, Lorenzo > xdp->data_end = xdp->data + data_len; > xdp_set_data_meta_invalid(xdp); > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > * platforms and 0B for 32-bit ones. > */ > -pp->rx_offset_correction = max(0, > +if (pp->bm_priv) > +pp->rx_offset_correction = max(0, > NET_SKB_PAD - > MVNETA_RX_PKT_OFFSET_CORRECTION); > } > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > Beste Grüße/Best regards > > Sven Auhagen > Dipl. Math. oec., M.Sc. > Voleatech GmbH > HRB: B 754643 > USTID: DE303643180 > Grathwohlstr. 5 > 72762 Reutlingen > Tel: +49 7121539550 > Fax: +49 7121539551 > E-Mail: sven.auhagen@voleatech.de > www.voleatech.de<https://www.voleatech.de> > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-22 22:57 ` lorenzo.bianconi @ 2020-01-24 12:03 ` Sven Auhagen 2020-01-25 11:11 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: Sven Auhagen @ 2020-01-24 12:03 UTC (permalink / raw) To: lorenzo.bianconi Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > Hi Sven, > > > Recently XDP Support was added to the mvneta driver for software buffer management. > > I tested XDP with my armada 388 board. It has hardware buffer management defined in the device tree file. > > I disabled the mvneta_bm module to test XDP. > > > > I found multiple problems. > > > > 1. With hardware buffer management enabled and mvneta_bm disabled the rx_offset was set to 0 with armhf (32 bit) which leads to no headroom in XDP and therefore the XDP Redirect did not work. > > 2. Removing the hardware buffer management from the device tree file completely made the mvneta driver unusable as it did not work anymore. > > Do you mean removing 'buffer-manager' property from the device tree? Yes removing it from each nics device tree definition. The if statement is not used in that case and the rx_offset_correction is always MVNETA_SKB_HEADROOM. > > > > > After some debugging I found out that xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; has to be xdp->data = data + pp->rx_offset_correction; if pp->rx_offset_correction > 0. > > I am not sure why and I am looking for help if someone is seeing the same on an arm64 board. > > Are you sure the hw does not insert the mvneta header before the data? It seems > to me that it is added even for hw buffer devices (according to the code) It is definitely possible. The 2 bytes before the data are 0. I believe the mvneta header is also 0 when no switch is attached. Is it added when a hw buffer capable device is not using and initializing the hw buffer? Do you have any documentation regarding the header? I have access to the Marvell Extranet but could not find anything. > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > Any feedback is appreciated. > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > prefetch(data); > > > > xdp->data_hard_start = data; > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > +xdp->data = data + pp->rx_offset_correction; > > This will break XDP support for 'real' sw buffer devices like Espressobin. The current code seems to break real hw buffer devices using sw buffer on armhf though. Best Sven > > Regards, > Lorenzo > > > xdp->data_end = xdp->data + data_len; > > xdp_set_data_meta_invalid(xdp); > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > * platforms and 0B for 32-bit ones. > > */ > > -pp->rx_offset_correction = max(0, > > +if (pp->bm_priv) > > +pp->rx_offset_correction = max(0, > > NET_SKB_PAD - > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > } > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > Beste Grüße/Best regards > > > > Sven Auhagen > > Dipl. Math. oec., M.Sc. > > Voleatech GmbH > > HRB: B 754643 > > USTID: DE303643180 > > Grathwohlstr. 5 > > 72762 Reutlingen > > Tel: +49 7121539550 > > Fax: +49 7121539551 > > E-Mail: sven.auhagen@voleatech.de > > www.voleatech.de<https://www.voleatech.de> > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-24 12:03 ` Sven Auhagen @ 2020-01-25 11:11 ` Sven Auhagen 2020-01-25 16:30 ` Lorenzo Bianconi 0 siblings, 1 reply; 8+ messages in thread From: Sven Auhagen @ 2020-01-25 11:11 UTC (permalink / raw) To: lorenzo.bianconi Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski On Fri, Jan 24, 2020 at 12:03:46PM +0000, Sven Auhagen wrote: > On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > > Hi Sven, > > > > > Recently XDP Support was added to the mvneta driver for software buffer management. > > > I tested XDP with my armada 388 board. It has hardware buffer management defined in the device tree file. > > > I disabled the mvneta_bm module to test XDP. > > > > > > I found multiple problems. > > > > > > 1. With hardware buffer management enabled and mvneta_bm disabled the rx_offset was set to 0 with armhf (32 bit) which leads to no headroom in XDP and therefore the XDP Redirect did not work. > > > 2. Removing the hardware buffer management from the device tree file completely made the mvneta driver unusable as it did not work anymore. > > > > Do you mean removing 'buffer-manager' property from the device tree? > > Yes removing it from each nics device tree definition. > The if statement is not used in that case and the rx_offset_correction is always MVNETA_SKB_HEADROOM. > > > > > > > > > After some debugging I found out that xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; has to be xdp->data = data + pp->rx_offset_correction; if pp->rx_offset_correction > 0. > > > I am not sure why and I am looking for help if someone is seeing the same on an arm64 board. > > > > Are you sure the hw does not insert the mvneta header before the data? It seems > > to me that it is added even for hw buffer devices (according to the code) > > It is definitely possible. The 2 bytes before the data are 0. I believe > the mvneta header is also 0 when no switch is attached. > Is it added when a hw buffer capable device is not using and initializing > the hw buffer? > > Do you have any documentation regarding the header? > I have access to the Marvell Extranet but could not find anything. I think I found the problem. I found the documentation finally and it states: The physical buffer pointer must be 64-bit aligned; therefore, bits[2:0] of the pointers are considered as zeros. rx_offset is defined as MVNETA_SKB_HEADROOM which in turn is: #define MVNETA_SKB_HEADROOM (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ NET_IP_ALIGN) this leads to an offset on armhf of 258 which is not 64 bit aligned and therefore shortened to 256 hence the MH header is actually at 256. This would explain my problem. Any thoughts? Best Sven > > > > > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > > > Any feedback is appreciated. > > > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > > prefetch(data); > > > > > > xdp->data_hard_start = data; > > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > > +xdp->data = data + pp->rx_offset_correction; > > > > This will break XDP support for 'real' sw buffer devices like Espressobin. > > The current code seems to break real hw buffer devices using sw buffer on armhf though. > > Best > Sven > > > > > Regards, > > Lorenzo > > > > > xdp->data_end = xdp->data + data_len; > > > xdp_set_data_meta_invalid(xdp); > > > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > > * platforms and 0B for 32-bit ones. > > > */ > > > -pp->rx_offset_correction = max(0, > > > +if (pp->bm_priv) > > > +pp->rx_offset_correction = max(0, > > > NET_SKB_PAD - > > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > > } > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > Beste Grüße/Best regards > > > > > > Sven Auhagen > > > Dipl. Math. oec., M.Sc. > > > Voleatech GmbH > > > HRB: B 754643 > > > USTID: DE303643180 > > > Grathwohlstr. 5 > > > 72762 Reutlingen > > > Tel: +49 7121539550 > > > Fax: +49 7121539551 > > > E-Mail: sven.auhagen@voleatech.de > > > https://eur03.safelinks.protection.outlook.com/?url=www.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=PlhiaiQCqIc9Pmkux%2B8xLf%2FiwP3Nn3UsMRozhbX%2FR%2B0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=sSpe8NSqXN8dJOp%2Fb%2FaaHcEPTdtT4jE59ek97VvTtlY%3D&reserved=0> > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-25 11:11 ` Sven Auhagen @ 2020-01-25 16:30 ` Lorenzo Bianconi 2020-01-27 9:04 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: Lorenzo Bianconi @ 2020-01-25 16:30 UTC (permalink / raw) To: Sven Auhagen Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski [-- Attachment #1: Type: text/plain, Size: 7463 bytes --] > On Fri, Jan 24, 2020 at 12:03:46PM +0000, Sven Auhagen wrote: > > On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > > > Hi Sven, > > > [...] > > I think I found the problem. I found the documentation finally and it states: > > The physical buffer pointer must be 64-bit aligned; therefore, bits[2:0] of the pointers are considered as zeros. > > rx_offset is defined as MVNETA_SKB_HEADROOM which in turn is: > > #define MVNETA_SKB_HEADROOM(max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ > NET_IP_ALIGN) > > this leads to an offset on armhf of 258 which is not 64 bit aligned and therefore > shortened to 256 hence the MH header is actually at 256. > > This would explain my problem. > > Any thoughts? Hi Sven, IIUC how the hw works, I guess we can reduce MVNETA_SKB_HEADROOM and let the hw put the MH header to align the IP header. Could you please try the following patch? Regards, Lorenzo diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c index 67ad8b8b127d..c032cffa6ae8 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -324,8 +324,7 @@ ETH_HLEN + ETH_FCS_LEN, \ cache_line_size()) -#define MVNETA_SKB_HEADROOM (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ - NET_IP_ALIGN) +#define MVNETA_SKB_HEADROOM max(XDP_PACKET_HEADROOM, NET_SKB_PAD) #define MVNETA_SKB_PAD (SKB_DATA_ALIGN(sizeof(struct skb_shared_info) + \ MVNETA_SKB_HEADROOM)) #define MVNETA_SKB_SIZE(len) (SKB_DATA_ALIGN(len) + MVNETA_SKB_PAD) @@ -1167,6 +1166,7 @@ static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); pp->bm_priv = NULL; + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); } @@ -4942,7 +4942,6 @@ static int mvneta_probe(struct platform_device *pdev) SET_NETDEV_DEV(dev, &pdev->dev); pp->id = global_port_id++; - pp->rx_offset_correction = MVNETA_SKB_HEADROOM; /* Obtain access to BM resources if enabled and already initialized */ bm_node = of_parse_phandle(dn, "buffer-manager", 0); @@ -4967,6 +4966,10 @@ static int mvneta_probe(struct platform_device *pdev) } of_node_put(bm_node); + /* sw buffer management */ + if (!pp->bm_priv) + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; + err = mvneta_init(&pdev->dev, pp); if (err < 0) goto err_netdev; @@ -5124,6 +5127,7 @@ static int mvneta_resume(struct device *device) err = mvneta_bm_port_init(pdev, pp); if (err < 0) { dev_info(&pdev->dev, "use SW buffer management\n"); + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; pp->bm_priv = NULL; } } > > Best > Sven > > > > > > > > > > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > > > > > Any feedback is appreciated. > > > > > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > > > prefetch(data); > > > > > > > > xdp->data_hard_start = data; > > > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > > > +xdp->data = data + pp->rx_offset_correction; > > > > > > This will break XDP support for 'real' sw buffer devices like Espressobin. > > > > The current code seems to break real hw buffer devices using sw buffer on armhf though. > > > > Best > > Sven > > > > > > > > Regards, > > > Lorenzo > > > > > > > xdp->data_end = xdp->data + data_len; > > > > xdp_set_data_meta_invalid(xdp); > > > > > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > > > * platforms and 0B for 32-bit ones. > > > > */ > > > > -pp->rx_offset_correction = max(0, > > > > +if (pp->bm_priv) > > > > +pp->rx_offset_correction = max(0, > > > > NET_SKB_PAD - > > > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > > > } > > > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > > > Beste Grüße/Best regards > > > > > > > > Sven Auhagen > > > > Dipl. Math. oec., M.Sc. > > > > Voleatech GmbH > > > > HRB: B 754643 > > > > USTID: DE303643180 > > > > Grathwohlstr. 5 > > > > 72762 Reutlingen > > > > Tel: +49 7121539550 > > > > Fax: +49 7121539551 > > > > E-Mail: sven.auhagen@voleatech.de > > > > https://eur03.safelinks.protection.outlook.com/?url=www.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=PlhiaiQCqIc9Pmkux%2B8xLf%2FiwP3Nn3UsMRozhbX%2FR%2B0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=sSpe8NSqXN8dJOp%2Fb%2FaaHcEPTdtT4jE59ek97VvTtlY%3D&reserved=0> > > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > Beste Grüße/Best regards > > Sven Auhagen > Dipl. Math. oec., M.Sc. > Voleatech GmbH > HRB: B 754643 > USTID: DE303643180 > Grathwohlstr. 5 > 72762 Reutlingen > Tel: +49 7121539550 > Fax: +49 7121539551 > E-Mail: sven.auhagen@voleatech.de > www.voleatech.de<https://www.voleatech.de> > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-25 16:30 ` Lorenzo Bianconi @ 2020-01-27 9:04 ` Sven Auhagen 2020-01-27 9:37 ` Lorenzo Bianconi 0 siblings, 1 reply; 8+ messages in thread From: Sven Auhagen @ 2020-01-27 9:04 UTC (permalink / raw) To: Lorenzo Bianconi Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski On Sat, Jan 25, 2020 at 05:30:16PM +0100, Lorenzo Bianconi wrote: > > On Fri, Jan 24, 2020 at 12:03:46PM +0000, Sven Auhagen wrote: > > > On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > > > > Hi Sven, > > > > > > [...] > > > > > I think I found the problem. I found the documentation finally and it states: > > > > The physical buffer pointer must be 64-bit aligned; therefore, bits[2:0] of the pointers are considered as zeros. > > > > rx_offset is defined as MVNETA_SKB_HEADROOM which in turn is: > > > > #define MVNETA_SKB_HEADROOM(max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ > > NET_IP_ALIGN) > > > > this leads to an offset on armhf of 258 which is not 64 bit aligned and therefore > > shortened to 256 hence the MH header is actually at 256. > > > > This would explain my problem. > > > > Any thoughts? > > Hi Sven, > > IIUC how the hw works, I guess we can reduce MVNETA_SKB_HEADROOM and let the hw put the MH > header to align the IP header. Could you please try the following patch? > > Regards, > Lorenzo > > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c > index 67ad8b8b127d..c032cffa6ae8 100644 > --- a/drivers/net/ethernet/marvell/mvneta.c > +++ b/drivers/net/ethernet/marvell/mvneta.c > @@ -324,8 +324,7 @@ > ETH_HLEN + ETH_FCS_LEN, \ > cache_line_size()) > > -#define MVNETA_SKB_HEADROOM (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ > - NET_IP_ALIGN) > +#define MVNETA_SKB_HEADROOM max(XDP_PACKET_HEADROOM, NET_SKB_PAD) > #define MVNETA_SKB_PAD (SKB_DATA_ALIGN(sizeof(struct skb_shared_info) + \ > MVNETA_SKB_HEADROOM)) > #define MVNETA_SKB_SIZE(len) (SKB_DATA_ALIGN(len) + MVNETA_SKB_PAD) > @@ -1167,6 +1166,7 @@ static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) > mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); > > pp->bm_priv = NULL; > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); > netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); > } > @@ -4942,7 +4942,6 @@ static int mvneta_probe(struct platform_device *pdev) > SET_NETDEV_DEV(dev, &pdev->dev); > > pp->id = global_port_id++; > - pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > /* Obtain access to BM resources if enabled and already initialized */ > bm_node = of_parse_phandle(dn, "buffer-manager", 0); > @@ -4967,6 +4966,10 @@ static int mvneta_probe(struct platform_device *pdev) > } > of_node_put(bm_node); > > + /* sw buffer management */ > + if (!pp->bm_priv) > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > + > err = mvneta_init(&pdev->dev, pp); > if (err < 0) > goto err_netdev; > @@ -5124,6 +5127,7 @@ static int mvneta_resume(struct device *device) > err = mvneta_bm_port_init(pdev, pp); > if (err < 0) { > dev_info(&pdev->dev, "use SW buffer management\n"); > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > pp->bm_priv = NULL; > } > } This patch works on my armada 388 board, thanks. Are you going to send in the patch? Best Sven > > > > > Best > > Sven > > > > > > > > > > > > > > > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > > > > > > > Any feedback is appreciated. > > > > > > > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > > > > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > > > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > > > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > > > > prefetch(data); > > > > > > > > > > xdp->data_hard_start = data; > > > > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > > > > +xdp->data = data + pp->rx_offset_correction; > > > > > > > > This will break XDP support for 'real' sw buffer devices like Espressobin. > > > > > > The current code seems to break real hw buffer devices using sw buffer on armhf though. > > > > > > Best > > > Sven > > > > > > > > > > > Regards, > > > > Lorenzo > > > > > > > > > xdp->data_end = xdp->data + data_len; > > > > > xdp_set_data_meta_invalid(xdp); > > > > > > > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > > > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > > > > * platforms and 0B for 32-bit ones. > > > > > */ > > > > > -pp->rx_offset_correction = max(0, > > > > > +if (pp->bm_priv) > > > > > +pp->rx_offset_correction = max(0, > > > > > NET_SKB_PAD - > > > > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > > > > > Beste Grüße/Best regards > > > > > > > > > > Sven Auhagen > > > > > Dipl. Math. oec., M.Sc. > > > > > Voleatech GmbH > > > > > HRB: B 754643 > > > > > USTID: DE303643180 > > > > > Grathwohlstr. 5 > > > > > 72762 Reutlingen > > > > > Tel: +49 7121539550 > > > > > Fax: +49 7121539551 > > > > > E-Mail: sven.auhagen@voleatech.de > > > > > https://eur03.safelinks.protection.outlook.com/?url=www.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=PlhiaiQCqIc9Pmkux%2B8xLf%2FiwP3Nn3UsMRozhbX%2FR%2B0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=sSpe8NSqXN8dJOp%2Fb%2FaaHcEPTdtT4jE59ek97VvTtlY%3D&reserved=0> > > > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > Beste Grüße/Best regards > > > > Sven Auhagen > > Dipl. Math. oec., M.Sc. > > Voleatech GmbH > > HRB: B 754643 > > USTID: DE303643180 > > Grathwohlstr. 5 > > 72762 Reutlingen > > Tel: +49 7121539550 > > Fax: +49 7121539551 > > E-Mail: sven.auhagen@voleatech.de > > www.voleatech.de<https://www.voleatech.de> > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-27 9:04 ` Sven Auhagen @ 2020-01-27 9:37 ` Lorenzo Bianconi 2020-01-27 9:56 ` Sven Auhagen 0 siblings, 1 reply; 8+ messages in thread From: Lorenzo Bianconi @ 2020-01-27 9:37 UTC (permalink / raw) To: Sven Auhagen, Andrew Lunn Cc: netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski [-- Attachment #1: Type: text/plain, Size: 7965 bytes --] > On Sat, Jan 25, 2020 at 05:30:16PM +0100, Lorenzo Bianconi wrote: > > > On Fri, Jan 24, 2020 at 12:03:46PM +0000, Sven Auhagen wrote: > > > > On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > > > > > Hi Sven, > > > > > > > > > [...] > > > > > [...] > > > > Hi Sven, > > > > IIUC how the hw works, I guess we can reduce MVNETA_SKB_HEADROOM and let the hw put the MH > > header to align the IP header. Could you please try the following patch? > > > > Regards, > > Lorenzo > > > > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c > > index 67ad8b8b127d..c032cffa6ae8 100644 > > --- a/drivers/net/ethernet/marvell/mvneta.c > > +++ b/drivers/net/ethernet/marvell/mvneta.c > > @@ -324,8 +324,7 @@ > > ETH_HLEN + ETH_FCS_LEN, \ > > cache_line_size()) > > > > -#define MVNETA_SKB_HEADROOM (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ > > - NET_IP_ALIGN) > > +#define MVNETA_SKB_HEADROOM max(XDP_PACKET_HEADROOM, NET_SKB_PAD) > > #define MVNETA_SKB_PAD (SKB_DATA_ALIGN(sizeof(struct skb_shared_info) + \ > > MVNETA_SKB_HEADROOM)) > > #define MVNETA_SKB_SIZE(len) (SKB_DATA_ALIGN(len) + MVNETA_SKB_PAD) > > @@ -1167,6 +1166,7 @@ static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) > > mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); > > > > pp->bm_priv = NULL; > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); > > netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); > > } > > @@ -4942,7 +4942,6 @@ static int mvneta_probe(struct platform_device *pdev) > > SET_NETDEV_DEV(dev, &pdev->dev); > > > > pp->id = global_port_id++; > > - pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > > > /* Obtain access to BM resources if enabled and already initialized */ > > bm_node = of_parse_phandle(dn, "buffer-manager", 0); > > @@ -4967,6 +4966,10 @@ static int mvneta_probe(struct platform_device *pdev) > > } > > of_node_put(bm_node); > > > > + /* sw buffer management */ > > + if (!pp->bm_priv) > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > + > > err = mvneta_init(&pdev->dev, pp); > > if (err < 0) > > goto err_netdev; > > @@ -5124,6 +5127,7 @@ static int mvneta_resume(struct device *device) > > err = mvneta_bm_port_init(pdev, pp); > > if (err < 0) { > > dev_info(&pdev->dev, "use SW buffer management\n"); > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > pp->bm_priv = NULL; > > } > > } > > This patch works on my armada 388 board, thanks. cool, thx for testing it. Is XDP support working on your board following back in sw bm? > Are you going to send in the patch? I will test it on my espressobin and then I will post it. @Andrew: applying this patch, is WRT1900ac working in your configuration? Regards, Lorenzo > > Best > Sven > > > > > > > > > Best > > > Sven > > > > > > > > > > > > > > > > > > > > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > > > > > > > > > Any feedback is appreciated. > > > > > > > > > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > > > > > > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > > > > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > > > > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > > > > > prefetch(data); > > > > > > > > > > > > xdp->data_hard_start = data; > > > > > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > > > > > +xdp->data = data + pp->rx_offset_correction; > > > > > > > > > > This will break XDP support for 'real' sw buffer devices like Espressobin. > > > > > > > > The current code seems to break real hw buffer devices using sw buffer on armhf though. > > > > > > > > Best > > > > Sven > > > > > > > > > > > > > > Regards, > > > > > Lorenzo > > > > > > > > > > > xdp->data_end = xdp->data + data_len; > > > > > > xdp_set_data_meta_invalid(xdp); > > > > > > > > > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > > > > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > > > > > * platforms and 0B for 32-bit ones. > > > > > > */ > > > > > > -pp->rx_offset_correction = max(0, > > > > > > +if (pp->bm_priv) > > > > > > +pp->rx_offset_correction = max(0, > > > > > > NET_SKB_PAD - > > > > > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > > > > > > > Beste Grüße/Best regards > > > > > > > > > > > > Sven Auhagen > > > > > > Dipl. Math. oec., M.Sc. > > > > > > Voleatech GmbH > > > > > > HRB: B 754643 > > > > > > USTID: DE303643180 > > > > > > Grathwohlstr. 5 > > > > > > 72762 Reutlingen > > > > > > Tel: +49 7121539550 > > > > > > Fax: +49 7121539551 > > > > > > E-Mail: sven.auhagen@voleatech.de > > > > > > https://eur03.safelinks.protection.outlook.com/?url=www.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=PlhiaiQCqIc9Pmkux%2B8xLf%2FiwP3Nn3UsMRozhbX%2FR%2B0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=sSpe8NSqXN8dJOp%2Fb%2FaaHcEPTdtT4jE59ek97VvTtlY%3D&reserved=0> > > > > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > Beste Grüße/Best regards > > > > > > Sven Auhagen > > > Dipl. Math. oec., M.Sc. > > > Voleatech GmbH > > > HRB: B 754643 > > > USTID: DE303643180 > > > Grathwohlstr. 5 > > > 72762 Reutlingen > > > Tel: +49 7121539550 > > > Fax: +49 7121539551 > > > E-Mail: sven.auhagen@voleatech.de > > > www.voleatech.de<https://www.voleatech.de> > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] mvneta driver XDP fixes armhf 2020-01-27 9:37 ` Lorenzo Bianconi @ 2020-01-27 9:56 ` Sven Auhagen 0 siblings, 0 replies; 8+ messages in thread From: Sven Auhagen @ 2020-01-27 9:56 UTC (permalink / raw) To: Lorenzo Bianconi Cc: Andrew Lunn, netdev, davem, thomas.petazzoni, brouer, ilias.apalodimas, matteo.croce, mw, jakub.kicinski On Mon, Jan 27, 2020 at 10:37:15AM +0100, Lorenzo Bianconi wrote: > > On Sat, Jan 25, 2020 at 05:30:16PM +0100, Lorenzo Bianconi wrote: > > > > On Fri, Jan 24, 2020 at 12:03:46PM +0000, Sven Auhagen wrote: > > > > > On Wed, Jan 22, 2020 at 11:57:40PM +0100, lorenzo.bianconi@redhat.com wrote: > > > > > > Hi Sven, > > > > > > > > > > > > [...] > > > > > > > > > [...] > > > > > > > Hi Sven, > > > > > > IIUC how the hw works, I guess we can reduce MVNETA_SKB_HEADROOM and let the hw put the MH > > > header to align the IP header. Could you please try the following patch? > > > > > > Regards, > > > Lorenzo > > > > > > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c > > > index 67ad8b8b127d..c032cffa6ae8 100644 > > > --- a/drivers/net/ethernet/marvell/mvneta.c > > > +++ b/drivers/net/ethernet/marvell/mvneta.c > > > @@ -324,8 +324,7 @@ > > > ETH_HLEN + ETH_FCS_LEN, \ > > > cache_line_size()) > > > > > > -#define MVNETA_SKB_HEADROOM (max(XDP_PACKET_HEADROOM, NET_SKB_PAD) + \ > > > - NET_IP_ALIGN) > > > +#define MVNETA_SKB_HEADROOM max(XDP_PACKET_HEADROOM, NET_SKB_PAD) > > > #define MVNETA_SKB_PAD (SKB_DATA_ALIGN(sizeof(struct skb_shared_info) + \ > > > MVNETA_SKB_HEADROOM)) > > > #define MVNETA_SKB_SIZE(len) (SKB_DATA_ALIGN(len) + MVNETA_SKB_PAD) > > > @@ -1167,6 +1166,7 @@ static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu) > > > mvneta_bm_pool_destroy(pp->bm_priv, pp->pool_short, 1 << pp->id); > > > > > > pp->bm_priv = NULL; > > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > > mvreg_write(pp, MVNETA_ACC_MODE, MVNETA_ACC_MODE_EXT1); > > > netdev_info(pp->dev, "fail to update MTU, fall back to software BM\n"); > > > } > > > @@ -4942,7 +4942,6 @@ static int mvneta_probe(struct platform_device *pdev) > > > SET_NETDEV_DEV(dev, &pdev->dev); > > > > > > pp->id = global_port_id++; > > > - pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > > > > > /* Obtain access to BM resources if enabled and already initialized */ > > > bm_node = of_parse_phandle(dn, "buffer-manager", 0); > > > @@ -4967,6 +4966,10 @@ static int mvneta_probe(struct platform_device *pdev) > > > } > > > of_node_put(bm_node); > > > > > > + /* sw buffer management */ > > > + if (!pp->bm_priv) > > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > > + > > > err = mvneta_init(&pdev->dev, pp); > > > if (err < 0) > > > goto err_netdev; > > > @@ -5124,6 +5127,7 @@ static int mvneta_resume(struct device *device) > > > err = mvneta_bm_port_init(pdev, pp); > > > if (err < 0) { > > > dev_info(&pdev->dev, "use SW buffer management\n"); > > > + pp->rx_offset_correction = MVNETA_SKB_HEADROOM; > > > pp->bm_priv = NULL; > > > } > > > } > > > > This patch works on my armada 388 board, thanks. > > cool, thx for testing it. Is XDP support working on your board > following back in sw bm? Yes, XDP redirect also works on sw bm on my board. The performance is not really faster than non XDP forwarding though. Best Sven > > > Are you going to send in the patch? > > I will test it on my espressobin and then I will post it. > @Andrew: applying this patch, is WRT1900ac working in your configuration? > > Regards, > Lorenzo > > > > > Best > > Sven > > > > > > > > > > > > > Best > > > > Sven > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Attached is a patch that fixes the problem on my armhf platform, as said I am not sure if this is a universal fix or armhf only. > > > > > > > > > > > > > > Any feedback is appreciated. > > > > > > > > > > > > > > Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de> > > > > > > > > > > > > > > --- a/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:44:05.611395960 +0000 > > > > > > > +++ b/drivers/net/ethernet/marvell/mvneta.c2020-01-22 08:59:27.053739433 +0000 > > > > > > > @@ -2158,7 +2158,7 @@ mvneta_swbm_rx_frame(struct mvneta_port > > > > > > > prefetch(data); > > > > > > > > > > > > > > xdp->data_hard_start = data; > > > > > > > -xdp->data = data + pp->rx_offset_correction + MVNETA_MH_SIZE; > > > > > > > +xdp->data = data + pp->rx_offset_correction; > > > > > > > > > > > > This will break XDP support for 'real' sw buffer devices like Espressobin. > > > > > > > > > > The current code seems to break real hw buffer devices using sw buffer on armhf though. > > > > > > > > > > Best > > > > > Sven > > > > > > > > > > > > > > > > > Regards, > > > > > > Lorenzo > > > > > > > > > > > > > xdp->data_end = xdp->data + data_len; > > > > > > > xdp_set_data_meta_invalid(xdp); > > > > > > > > > > > > > > @@ -4960,7 +4960,8 @@ static int mvneta_probe(struct platform_ > > > > > > > * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit > > > > > > > * platforms and 0B for 32-bit ones. > > > > > > > */ > > > > > > > -pp->rx_offset_correction = max(0, > > > > > > > +if (pp->bm_priv) > > > > > > > +pp->rx_offset_correction = max(0, > > > > > > > NET_SKB_PAD - > > > > > > > MVNETA_RX_PKT_OFFSET_CORRECTION); > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > > > > > > > > > Beste Grüße/Best regards > > > > > > > > > > > > > > Sven Auhagen > > > > > > > Dipl. Math. oec., M.Sc. > > > > > > > Voleatech GmbH > > > > > > > HRB: B 754643 > > > > > > > USTID: DE303643180 > > > > > > > Grathwohlstr. 5 > > > > > > > 72762 Reutlingen > > > > > > > Tel: +49 7121539550 > > > > > > > Fax: +49 7121539551 > > > > > > > E-Mail: sven.auhagen@voleatech.de > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=www.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=PlhiaiQCqIc9Pmkux%2B8xLf%2FiwP3Nn3UsMRozhbX%2FR%2B0%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.voleatech.de&data=02%7C01%7Csven.auhagen%40voleatech.de%7C16ecc6de7670473d7de108d7a0c5cf85%7Cb82a99f679814a7295344d35298f847b%7C0%7C0%7C637154643755759442&sdata=sSpe8NSqXN8dJOp%2Fb%2FaaHcEPTdtT4jE59ek97VvTtlY%3D&reserved=0> > > > > > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > > > > > > > > > > > > > > > > > > > +++ Voleatech auf der E-World, 11. bis 13. Februar 2020, Halle 5, Stand 521 +++ > > > > > > > > Beste Grüße/Best regards > > > > > > > > Sven Auhagen > > > > Dipl. Math. oec., M.Sc. > > > > Voleatech GmbH > > > > HRB: B 754643 > > > > USTID: DE303643180 > > > > Grathwohlstr. 5 > > > > 72762 Reutlingen > > > > Tel: +49 7121539550 > > > > Fax: +49 7121539551 > > > > E-Mail: sven.auhagen@voleatech.de > > > > www.voleatech.de<https://www.voleatech.de> > > > > Diese Information ist ausschließlich für den Adressaten bestimmt und kann vertraulich oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Für den Adressaten sind die Informationen in dieser Mail nur zum persönlichen Gebrauch. Eine Weiterleitung darf nur nach Rücksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schließen wir jede Haftung aus. > > > > > > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-01-27 9:56 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-22 10:05 [PATCH] mvneta driver XDP fixes armhf Sven Auhagen 2020-01-22 22:57 ` lorenzo.bianconi 2020-01-24 12:03 ` Sven Auhagen 2020-01-25 11:11 ` Sven Auhagen 2020-01-25 16:30 ` Lorenzo Bianconi 2020-01-27 9:04 ` Sven Auhagen 2020-01-27 9:37 ` Lorenzo Bianconi 2020-01-27 9:56 ` Sven Auhagen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.