[PATCH v2 net 1/2] net: fec: correct the counting of XDP sent frames

[PATCH v2 net 1/2] net: fec: correct the counting of XDP sent frames

[Shenwei Wang]

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 <g.singh@nxp.com>
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
---
 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

[PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Shenwei Wang]

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 <shenwei.wang@nxp.com>
---
 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

Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Andrew Lunn]

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

RE: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Shenwei Wang]

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Tuesday, May 2, 2023 6:19 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller <davem@davemloft.net>;
> Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> Paolo Abeni <pabeni@redhat.com>; Clark Wang <xiaoning.wang@nxp.com>; dl-
> linux-imx <linux-imx@nxp.com>; Alexei Starovoitov <ast@kernel.org>; Daniel
> Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>; Alexander
> Lobakin <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> 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

Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Simon Horman]

On Wed, May 03, 2023 at 12:53:57PM +0000, Shenwei Wang wrote:
> 
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Tuesday, May 2, 2023 6:19 PM
> > To: Shenwei Wang <shenwei.wang@nxp.com>
> > Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller <davem@davemloft.net>;
> > Eric Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>;
> > Paolo Abeni <pabeni@redhat.com>; Clark Wang <xiaoning.wang@nxp.com>; dl-
> > linux-imx <linux-imx@nxp.com>; Alexei Starovoitov <ast@kernel.org>; Daniel
> > Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> > <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>; Alexander
> > Lobakin <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> > kernel@vger.kernel.org; imx@lists.linux.dev
> > 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.

RE: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Shenwei Wang]

> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Wednesday, May 3, 2023 10:34 AM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Wei Fang <wei.fang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark Wang
> <xiaoning.wang@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; Alexander Lobakin
> <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> 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 <andrew@lunn.ch>
> > > Sent: Tuesday, May 2, 2023 6:19 PM
> > > To: Shenwei Wang <shenwei.wang@nxp.com>
> > > Cc: Wei Fang <wei.fang@nxp.com>; David S. Miller
> > > <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> > > Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark
> > > Wang <xiaoning.wang@nxp.com>; dl- linux-imx <linux-imx@nxp.com>;
> > > Alexei Starovoitov <ast@kernel.org>; Daniel Borkmann
> > > <daniel@iogearbox.net>; Jesper Dangaard Brouer <hawk@kernel.org>;
> > > John Fastabend <john.fastabend@gmail.com>; Alexander Lobakin
> > > <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> > > kernel@vger.kernel.org; imx@lists.linux.dev
> > > 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

Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Simon Horman]

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

RE: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Shenwei Wang]

> -----Original Message-----
> From: Simon Horman <horms@kernel.org>
> Sent: Wednesday, May 3, 2023 2:07 PM
> To: Shenwei Wang <shenwei.wang@nxp.com>
> Cc: Andrew Lunn <andrew@lunn.ch>; Wei Fang <wei.fang@nxp.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Clark Wang
> <xiaoning.wang@nxp.com>; dl-linux-imx <linux-imx@nxp.com>; Alexei
> Starovoitov <ast@kernel.org>; Daniel Borkmann <daniel@iogearbox.net>;
> Jesper Dangaard Brouer <hawk@kernel.org>; John Fastabend
> <john.fastabend@gmail.com>; Alexander Lobakin
> <alexandr.lobakin@intel.com>; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; imx@lists.linux.dev
> 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 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'.
>

Hi Simon,

I'm a bit confused.

Are you suggesting that I submit the following restructuring patch for 'net' at this time?
[PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

Thanks,
Shenwei


> I would also suggest waiting 24h between posting v2 and v3, as per
> https://kernel.or/
> g%2Fdoc%2Fhtml%2Fnext%2Fprocess%2Fmaintainer-
> netdev.html&data=05%7C01%7Cshenwei.wang%40nxp.com%7Ca451f7a0cf674
> 0b0561d08db4c09a558%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7
> C638187376528990151%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C
> &sdata=wBrPt7eKO2Y8ve%2B%2BG8STtZZVS9YdQR11YUL6wcwJ29M%3D&rese
> rved=0
>

Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Andrew Lunn]

> Hi Simon,
> 
> I'm a bit confused.
> 
> Are you suggesting that I submit the following restructuring patch for 'net' at this time?
> [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations
> 
> Thanks,
> Shenwei

Submit the fix to 'net'. But only the fix.

Once a week, net gets merged to net-next, so the fix will also appear
in net-next. You can then do the cleanup in net-next.

   Andrew

Re: [EXT] Re: [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations

[Simon Horman]

On Wed, May 03, 2023 at 09:40:30PM +0200, Andrew Lunn wrote:
> > Hi Simon,
> > 
> > I'm a bit confused.
> > 
> > Are you suggesting that I submit the following restructuring patch for 'net' at this time?
> > [PATCH v2 net 2/2] net: fec: restructuring the functions to avoid forward declarations
> > 
> > Thanks,
> > Shenwei
> 
> Submit the fix to 'net'. But only the fix.

Yes, that is what I meant.

> Once a week, net gets merged to net-next, so the fix will also appear
> in net-next. You can then do the cleanup in net-next.