In the current xdp_xmit implementation, if any single frame fails to
transmit due to insufficient buffer descriptors, the function nevertheless
reports success in sending all frames. This results in erroneously
indicating that frames were transmitted when in fact they were dropped.
This patch fixes the issue by ensureing the return value properly
indicates the actual number of frames successfully transmitted, rather than
potentially reporting success for all frames when some could not transmit.
Fixes: 6d6b39f180b8 ("net: fec: add initial XDP support")
Signed-off-by: Gagandeep Singh <[email protected]>
Signed-off-by: Shenwei Wang <[email protected]>
---
v2:
- only keep the bug fix part of codes according to Horatiu's comments.
- restructure the functions to avoid the forward declaration.
drivers/net/ethernet/freescale/fec_main.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 160c1b3525f5..42ec6ca3bf03 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -3798,7 +3798,8 @@ static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
entries_free = fec_enet_get_free_txdesc_num(txq);
if (entries_free < MAX_SKB_FRAGS + 1) {
netdev_err(fep->netdev, "NOT enough BD for SG!\n");
- return NETDEV_TX_OK;
+ xdp_return_frame(frame);
+ return NETDEV_TX_BUSY;
}
/* Fill in a Tx ring entry */
@@ -3856,6 +3857,7 @@ static int fec_enet_xdp_xmit(struct net_device *dev,
struct fec_enet_private *fep = netdev_priv(dev);
struct fec_enet_priv_tx_q *txq;
int cpu = smp_processor_id();
+ unsigned int sent_frames = 0;
struct netdev_queue *nq;
unsigned int queue;
int i;
@@ -3866,8 +3868,11 @@ static int fec_enet_xdp_xmit(struct net_device *dev,
__netif_tx_lock(nq, cpu);
- for (i = 0; i < num_frames; i++)
- fec_enet_txq_xmit_frame(fep, txq, frames[i]);
+ for (i = 0; i < num_frames; i++) {
+ if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) != 0)
+ break;
+ sent_frames++;
+ }
/* Make sure the update to bdp and tx_skbuff are performed. */
wmb();
@@ -3877,7 +3882,7 @@ static int fec_enet_xdp_xmit(struct net_device *dev,
__netif_tx_unlock(nq);
- return num_frames;
+ return sent_frames;
}
static const struct net_device_ops fec_netdev_ops = {
--
2.34.1
The patch reorganizes functions related to XDP frame transmission, moving
them above the fec_enet_run_xdp implementation. This eliminates the need
for forward declarations of these functions.
Fixes: 6d6b39f180b8 ("net: fec: add initial XDP support")
Signed-off-by: Shenwei Wang <[email protected]>
---
drivers/net/ethernet/freescale/fec_main.c | 216 +++++++++++-----------
1 file changed, 108 insertions(+), 108 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 42ec6ca3bf03..14f9907f3ca2 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1511,6 +1511,114 @@ static void fec_enet_update_cbd(struct fec_enet_priv_rx_q *rxq,
bdp->cbd_bufaddr = cpu_to_fec32(phys_addr);
}
+static int
+fec_enet_xdp_get_tx_queue(struct fec_enet_private *fep, int index)
+{
+ if (unlikely(index < 0))
+ return 0;
+
+ return (index % fep->num_tx_queues);
+}
+
+static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
+ struct fec_enet_priv_tx_q *txq,
+ struct xdp_frame *frame)
+{
+ unsigned int index, status, estatus;
+ struct bufdesc *bdp, *last_bdp;
+ dma_addr_t dma_addr;
+ int entries_free;
+
+ entries_free = fec_enet_get_free_txdesc_num(txq);
+ if (entries_free < MAX_SKB_FRAGS + 1) {
+ netdev_err(fep->netdev, "NOT enough BD for SG!\n");
+ xdp_return_frame(frame);
+ return NETDEV_TX_BUSY;
+ }
+
+ /* Fill in a Tx ring entry */
+ bdp = txq->bd.cur;
+ last_bdp = bdp;
+ status = fec16_to_cpu(bdp->cbd_sc);
+ status &= ~BD_ENET_TX_STATS;
+
+ index = fec_enet_get_bd_index(bdp, &txq->bd);
+
+ dma_addr = dma_map_single(&fep->pdev->dev, frame->data,
+ frame->len, DMA_TO_DEVICE);
+ if (dma_mapping_error(&fep->pdev->dev, dma_addr))
+ return FEC_ENET_XDP_CONSUMED;
+
+ status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
+ if (fep->bufdesc_ex)
+ estatus = BD_ENET_TX_INT;
+
+ bdp->cbd_bufaddr = cpu_to_fec32(dma_addr);
+ bdp->cbd_datlen = cpu_to_fec16(frame->len);
+
+ if (fep->bufdesc_ex) {
+ struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
+
+ if (fep->quirks & FEC_QUIRK_HAS_AVB)
+ estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
+
+ ebdp->cbd_bdu = 0;
+ ebdp->cbd_esc = cpu_to_fec32(estatus);
+ }
+
+ index = fec_enet_get_bd_index(last_bdp, &txq->bd);
+ txq->tx_skbuff[index] = NULL;
+
+ /* Send it on its way. Tell FEC it's ready, interrupt when done,
+ * it's the last BD of the frame, and to put the CRC on the end.
+ */
+ status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
+ bdp->cbd_sc = cpu_to_fec16(status);
+
+ /* If this was the last BD in the ring, start at the beginning again. */
+ bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
+
+ txq->bd.cur = bdp;
+
+ return 0;
+}
+
+static int fec_enet_xdp_xmit(struct net_device *dev,
+ int num_frames,
+ struct xdp_frame **frames,
+ u32 flags)
+{
+ struct fec_enet_private *fep = netdev_priv(dev);
+ struct fec_enet_priv_tx_q *txq;
+ int cpu = smp_processor_id();
+ unsigned int sent_frames = 0;
+ struct netdev_queue *nq;
+ unsigned int queue;
+ int i;
+
+ queue = fec_enet_xdp_get_tx_queue(fep, cpu);
+ txq = fep->tx_queue[queue];
+ nq = netdev_get_tx_queue(fep->netdev, queue);
+
+ __netif_tx_lock(nq, cpu);
+
+ for (i = 0; i < num_frames; i++) {
+ if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) != 0)
+ break;
+ sent_frames++;
+ }
+
+ /* Make sure the update to bdp and tx_skbuff are performed. */
+ wmb();
+
+ /* Trigger transmission start */
+ writel(0, txq->bd.reg_desc_active);
+
+ __netif_tx_unlock(nq);
+
+ return sent_frames;
+}
+
static u32
fec_enet_run_xdp(struct fec_enet_private *fep, struct bpf_prog *prog,
struct xdp_buff *xdp, struct fec_enet_priv_rx_q *rxq, int index)
@@ -3777,114 +3885,6 @@ static int fec_enet_bpf(struct net_device *dev, struct netdev_bpf *bpf)
}
}
-static int
-fec_enet_xdp_get_tx_queue(struct fec_enet_private *fep, int index)
-{
- if (unlikely(index < 0))
- return 0;
-
- return (index % fep->num_tx_queues);
-}
-
-static int fec_enet_txq_xmit_frame(struct fec_enet_private *fep,
- struct fec_enet_priv_tx_q *txq,
- struct xdp_frame *frame)
-{
- unsigned int index, status, estatus;
- struct bufdesc *bdp, *last_bdp;
- dma_addr_t dma_addr;
- int entries_free;
-
- entries_free = fec_enet_get_free_txdesc_num(txq);
- if (entries_free < MAX_SKB_FRAGS + 1) {
- netdev_err(fep->netdev, "NOT enough BD for SG!\n");
- xdp_return_frame(frame);
- return NETDEV_TX_BUSY;
- }
-
- /* Fill in a Tx ring entry */
- bdp = txq->bd.cur;
- last_bdp = bdp;
- status = fec16_to_cpu(bdp->cbd_sc);
- status &= ~BD_ENET_TX_STATS;
-
- index = fec_enet_get_bd_index(bdp, &txq->bd);
-
- dma_addr = dma_map_single(&fep->pdev->dev, frame->data,
- frame->len, DMA_TO_DEVICE);
- if (dma_mapping_error(&fep->pdev->dev, dma_addr))
- return FEC_ENET_XDP_CONSUMED;
-
- status |= (BD_ENET_TX_INTR | BD_ENET_TX_LAST);
- if (fep->bufdesc_ex)
- estatus = BD_ENET_TX_INT;
-
- bdp->cbd_bufaddr = cpu_to_fec32(dma_addr);
- bdp->cbd_datlen = cpu_to_fec16(frame->len);
-
- if (fep->bufdesc_ex) {
- struct bufdesc_ex *ebdp = (struct bufdesc_ex *)bdp;
-
- if (fep->quirks & FEC_QUIRK_HAS_AVB)
- estatus |= FEC_TX_BD_FTYPE(txq->bd.qid);
-
- ebdp->cbd_bdu = 0;
- ebdp->cbd_esc = cpu_to_fec32(estatus);
- }
-
- index = fec_enet_get_bd_index(last_bdp, &txq->bd);
- txq->tx_skbuff[index] = NULL;
-
- /* Send it on its way. Tell FEC it's ready, interrupt when done,
- * it's the last BD of the frame, and to put the CRC on the end.
- */
- status |= (BD_ENET_TX_READY | BD_ENET_TX_TC);
- bdp->cbd_sc = cpu_to_fec16(status);
-
- /* If this was the last BD in the ring, start at the beginning again. */
- bdp = fec_enet_get_nextdesc(last_bdp, &txq->bd);
-
- txq->bd.cur = bdp;
-
- return 0;
-}
-
-static int fec_enet_xdp_xmit(struct net_device *dev,
- int num_frames,
- struct xdp_frame **frames,
- u32 flags)
-{
- struct fec_enet_private *fep = netdev_priv(dev);
- struct fec_enet_priv_tx_q *txq;
- int cpu = smp_processor_id();
- unsigned int sent_frames = 0;
- struct netdev_queue *nq;
- unsigned int queue;
- int i;
-
- queue = fec_enet_xdp_get_tx_queue(fep, cpu);
- txq = fep->tx_queue[queue];
- nq = netdev_get_tx_queue(fep->netdev, queue);
-
- __netif_tx_lock(nq, cpu);
-
- for (i = 0; i < num_frames; i++) {
- if (fec_enet_txq_xmit_frame(fep, txq, frames[i]) != 0)
- break;
- sent_frames++;
- }
-
- /* Make sure the update to bdp and tx_skbuff are performed. */
- wmb();
-
- /* Trigger transmission start */
- writel(0, txq->bd.reg_desc_active);
-
- __netif_tx_unlock(nq);
-
- return sent_frames;
-}
-
static const struct net_device_ops fec_netdev_ops = {
.ndo_open = fec_enet_open,
.ndo_stop = fec_enet_close,
--
2.34.1
On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> The patch reorganizes functions related to XDP frame transmission, moving
> them above the fec_enet_run_xdp implementation. This eliminates the need
> for forward declarations of these functions.
I'm confused. Are these two patches in the wrong order?
The reason that i asked you to fix the forward declaration in net-next
is that it makes your fix two patches. Sometimes that is not obvious
to people back porting patches, and one gets lost, causing build
problems. So it is better to have a single patch which is maybe not
100% best practice merged to stable, and then a cleanup patch merged
to the head of development.
Andrew
> -----Original Message-----
> From: Andrew Lunn <[email protected]>
> Sent: Tuesday, May 2, 2023 6:19 PM
> To: Shenwei Wang <[email protected]>
> Cc: Wei Fang <[email protected]>; David S. Miller <[email protected]>;
> Eric Dumazet <[email protected]>; Jakub Kicinski <[email protected]>;
> Paolo Abeni <[email protected]>; Clark Wang <[email protected]>; dl-
> linux-imx <[email protected]>; Alexei Starovoitov <[email protected]>; Daniel
> Borkmann <[email protected]>; Jesper Dangaard Brouer
> <[email protected]>; John Fastabend <[email protected]>; Alexander
> Lobakin <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]
> Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> avoid forward declarations
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > The patch reorganizes functions related to XDP frame transmission,
> > moving them above the fec_enet_run_xdp implementation. This eliminates
> > the need for forward declarations of these functions.
>
> I'm confused. Are these two patches in the wrong order?
>
> The reason that i asked you to fix the forward declaration in net-next is that it
> makes your fix two patches. Sometimes that is not obvious to people back
> porting patches, and one gets lost, causing build problems. So it is better to have
> a single patch which is maybe not 100% best practice merged to stable, and then
> a cleanup patch merged to the head of development.
>
If that is the case, we should forgo the second patch. Its purpose was to reorganize
function order such that the subsequent patch to net-next enabling XDP_TX would not
encounter forward declaration issues.
Thanks,
Shenwei
> Andrew
On Wed, May 03, 2023 at 12:53:57PM +0000, Shenwei Wang wrote:
>
>
> > -----Original Message-----
> > From: Andrew Lunn <[email protected]>
> > Sent: Tuesday, May 2, 2023 6:19 PM
> > To: Shenwei Wang <[email protected]>
> > Cc: Wei Fang <[email protected]>; David S. Miller <[email protected]>;
> > Eric Dumazet <[email protected]>; Jakub Kicinski <[email protected]>;
> > Paolo Abeni <[email protected]>; Clark Wang <[email protected]>; dl-
> > linux-imx <[email protected]>; Alexei Starovoitov <[email protected]>; Daniel
> > Borkmann <[email protected]>; Jesper Dangaard Brouer
> > <[email protected]>; John Fastabend <[email protected]>; Alexander
> > Lobakin <[email protected]>; [email protected]; linux-
> > [email protected]; [email protected]
> > Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> > avoid forward declarations
> >
> > Caution: This is an external email. Please take care when clicking links or
> > opening attachments. When in doubt, report the message using the 'Report this
> > email' button
> >
> >
> > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > The patch reorganizes functions related to XDP frame transmission,
> > > moving them above the fec_enet_run_xdp implementation. This eliminates
> > > the need for forward declarations of these functions.
> >
> > I'm confused. Are these two patches in the wrong order?
> >
> > The reason that i asked you to fix the forward declaration in net-next is that it
> > makes your fix two patches. Sometimes that is not obvious to people back
> > porting patches, and one gets lost, causing build problems. So it is better to have
> > a single patch which is maybe not 100% best practice merged to stable, and then
> > a cleanup patch merged to the head of development.
> >
>
> If that is the case, we should forgo the second patch. Its purpose was to
> reorganize function order such that the subsequent patch to net-next
> enabling XDP_TX would not encounter forward declaration issues.
I think a good plan would be, as I understood Andrew's original suggestion,
to:
1. Only have patch 2/2, targeted at 'net', for now
2. Later, once that patch has been accepted into 'net', 'net-next' has
reopened, and that patch is present in 'net-next', then follow-up
with patch 1/2, which is a cleanup.
> -----Original Message-----
> From: Simon Horman <[email protected]>
> Sent: Wednesday, May 3, 2023 10:34 AM
> To: Shenwei Wang <[email protected]>
> Cc: Andrew Lunn <[email protected]>; Wei Fang <[email protected]>; David S.
> Miller <[email protected]>; Eric Dumazet <[email protected]>; Jakub
> Kicinski <[email protected]>; Paolo Abeni <[email protected]>; Clark Wang
> <[email protected]>; dl-linux-imx <[email protected]>; Alexei
> Starovoitov <[email protected]>; Daniel Borkmann <[email protected]>;
> Jesper Dangaard Brouer <[email protected]>; John Fastabend
> <[email protected]>; Alexander Lobakin
> <[email protected]>; [email protected]; linux-
> [email protected]; [email protected]
> Subject: Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to
> avoid forward declarations
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Wed, May 03, 2023 at 12:53:57PM +0000, Shenwei Wang wrote:
> >
> >
> > > -----Original Message-----
> > > From: Andrew Lunn <[email protected]>
> > > Sent: Tuesday, May 2, 2023 6:19 PM
> > > To: Shenwei Wang <[email protected]>
> > > Cc: Wei Fang <[email protected]>; David S. Miller
> > > <[email protected]>; Eric Dumazet <[email protected]>; Jakub
> > > Kicinski <[email protected]>; Paolo Abeni <[email protected]>; Clark
> > > Wang <[email protected]>; dl- linux-imx <[email protected]>;
> > > Alexei Starovoitov <[email protected]>; Daniel Borkmann
> > > <[email protected]>; Jesper Dangaard Brouer <[email protected]>;
> > > John Fastabend <[email protected]>; Alexander Lobakin
> > > <[email protected]>; [email protected]; linux-
> > > [email protected]; [email protected]
> > > Subject: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the
> > > functions to avoid forward declarations
> > >
> > > Caution: This is an external email. Please take care when clicking
> > > links or opening attachments. When in doubt, report the message
> > > using the 'Report this email' button
> > >
> > >
> > > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > > The patch reorganizes functions related to XDP frame transmission,
> > > > moving them above the fec_enet_run_xdp implementation. This
> > > > eliminates the need for forward declarations of these functions.
> > >
> > > I'm confused. Are these two patches in the wrong order?
> > >
> > > The reason that i asked you to fix the forward declaration in
> > > net-next is that it makes your fix two patches. Sometimes that is
> > > not obvious to people back porting patches, and one gets lost,
> > > causing build problems. So it is better to have a single patch which
> > > is maybe not 100% best practice merged to stable, and then a cleanup patch
> merged to the head of development.
> > >
> >
> > If that is the case, we should forgo the second patch. Its purpose was
> > to reorganize function order such that the subsequent patch to
> > net-next enabling XDP_TX would not encounter forward declaration issues.
>
> I think a good plan would be, as I understood Andrew's original suggestion,
> to:
>
> 1. Only have patch 2/2, targeted at 'net', for now 2. Later, once that patch has
> been accepted into 'net', 'net-next' has
> reopened, and that patch is present in 'net-next', then follow-up
> with patch 1/2, which is a cleanup.
So should I re-submit the patch? Or you just take the 1st patch and drop the 2nd one?
Thanks,
Shenwei
On Wed, May 03, 2023 at 06:41:59PM +0000, Shenwei Wang wrote:
...
> > > > On Tue, May 02, 2023 at 05:08:18PM -0500, Shenwei Wang wrote:
> > > > > The patch reorganizes functions related to XDP frame transmission,
> > > > > moving them above the fec_enet_run_xdp implementation. This
> > > > > eliminates the need for forward declarations of these functions.
> > > >
> > > > I'm confused. Are these two patches in the wrong order?
> > > >
> > > > The reason that i asked you to fix the forward declaration in
> > > > net-next is that it makes your fix two patches. Sometimes that is
> > > > not obvious to people back porting patches, and one gets lost,
> > > > causing build problems. So it is better to have a single patch which
> > > > is maybe not 100% best practice merged to stable, and then a cleanup patch
> > merged to the head of development.
> > > >
> > >
> > > If that is the case, we should forgo the second patch. Its purpose was
> > > to reorganize function order such that the subsequent patch to
> > > net-next enabling XDP_TX would not encounter forward declaration issues.
> >
> > I think a good plan would be, as I understood Andrew's original suggestion,
> > to:
> >
> > 1. Only have patch 2/2, targeted at 'net', for now 2. Later, once that patch has
> > been accepted into 'net', 'net-next' has
> > reopened, and that patch is present in 'net-next', then follow-up
> > with patch 1/2, which is a cleanup.
>
> So should I re-submit the patch? Or you just take the 1st patch and drop
> the 2nd one?
net and net-next work on a granularity of patch-sets.
So I would suggest re-submitting only patch 2/2 for 'net'.
I would also suggest waiting 24h between posting v2 and v3,
as per https://kernel.org/doc/html/next/process/maintainer-netdev.html