All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Lai <justinlai0215@realtek.com>
To: Simon Horman <horms@kernel.org>
Cc: Markus Elfring <Markus.Elfring@web.de>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>, Andrew Lunn <andrew@lunn.ch>,
	Hariprasad Kelam <hkelam@marvell.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Larry Chiu <larry.chiu@realtek.com>,
	Ping-Ke Shih <pkshih@realtek.com>,
	Ratheesh Kannoth <rkannoth@marvell.com>
Subject: RE: [v20 02/13] rtase: Implement the .ndo_open function
Date: Tue, 18 Jun 2024 07:51:19 +0000	[thread overview]
Message-ID: <416da6e14d134caeaa4bfe29291f0eb2@realtek.com> (raw)
In-Reply-To: <20240617185956.GY8447@kernel.org>

> On Mon, Jun 17, 2024 at 01:28:51PM +0000, Justin Lai wrote:
> >
> > > >> How do you think about to increase the application of scope-based
> > > >> resource
> > > management?
> > > >> https://elixir.bootlin.com/linux/v6.10-rc3/source/include/linux/c
> > > >> lean
> > > >> up.h#L8
> > > >
> > > > Due to our tx and rx each having multiple queues that need to
> > > > allocate descriptors, if any one of the queues fails to allocate,
> > > > rtase_alloc_desc() will return an error. Therefore, using 'goto'
> > > > here rather than directly returning seems to be reasonable.
> > >
> > > Some goto chains can be replaced by further usage of advanced
> > > cleanup techniques, can't they?
> > >
> > > Regards,
> > > Markus
> >
> > rtase_alloc_desc() is used to allocate DMA memory.
> > I'd like to ask if it's better to keep our current method?
> 
> Hi Justin,
> 
> It may be the case that the techniques recently added by cleanup.h could be
> used here. But, OTOH, it is the case that using goto for unwinding errors is in
> keeping with current Networking driver best practices.
> 
> Regardless of the above, I would suggest that if an error occurs in
> rtase_alloc_desc() then it release any resources it has allocated. Assuming the
> elements of tp->tx_ring and tp->rx_ring are initialised to NULL when
> rtase_alloc_desc is called, it looks like that can be achieved by
> rtase_alloc_desc() calling rtase_free_desc().
> 
> Something like the following (completely untested!).
> Please also note that there is probably no need to call netdev_err on error, as
> the memory core should already log on error.
> 
> static int rtase_alloc_desc(struct rtase_private *tp) {
>         struct pci_dev *pdev = tp->pdev;
>         u32 i;
> 
>         /* rx and tx descriptors needs 256 bytes alignment.
>          * dma_alloc_coherent provides more.
>          */
>         for (i = 0; i < tp->func_tx_queue_num; i++) {
>                 tp->tx_ring[i].desc =
>                                 dma_alloc_coherent(&pdev->dev,
> 
> RTASE_TX_RING_DESC_SIZE,
> 
> &tp->tx_ring[i].phy_addr,
>                                                    GFP_KERNEL);
>                 if (!tp->tx_ring[i].desc)
>                         goto err;
>         }
> 
>         for (i = 0; i < tp->func_rx_queue_num; i++) {
>                 tp->rx_ring[i].desc =
>                                 dma_alloc_coherent(&pdev->dev,
> 
> RTASE_RX_RING_DESC_SIZE,
> 
> &tp->rx_ring[i].phy_addr,
>                                                    GFP_KERNEL);
>                 if (!tp->rx_ring[i].desc)
>                         goto err;
>                 }
>         }
> 
>         return 0;
> 
> err:
>         rtase_free_desc(tp)
>         return -ENOMEM;
> }
> 
> And then rtase_alloc_desc can be called like this in rtase_open():
> 
> static int rtase_open(struct net_device *dev) {
>         struct rtase_private *tp = netdev_priv(dev);
>         const struct pci_dev *pdev = tp->pdev;
>         struct rtase_int_vector *ivec;
>         u16 i = 0, j;
>         int ret;
> 
>         ivec = &tp->int_vector[0];
>         tp->rx_buf_sz = RTASE_RX_BUF_SIZE;
> 
>         ret = rtase_alloc_desc(tp);
>         if (ret)
>                 return ret;
> 
>         ret = rtase_init_ring(dev);
>         if (ret)
>                 goto err_free_all_allocated_mem;
> 
> ...
> 
> err_free_all_allocated_mem:
>         rtase_free_desc(tp);
> 
>         return ret;
> }
> 
> This is would be in keeping with my understanding of best practices for
> Networking drivers: that callers don't have to worry about cleaning up
> resources allocated by functions that return an error.
> 
> 
> I would also suggest reading Markus's advice with due care, as it is not always
> aligned with best practice for Networking code.

Hi Simon,
Thank you for your response. Based on your suggestion, if the descriptor
allocation of DMA memory fails, I will directly do error handling in
rtase_alloc_desc() using the 'goto' method. Moreover, in the error
handling section, I will call rtase_free_desc(tp) to free the already
allocated descriptor.


  parent reply	other threads:[~2024-06-18  7:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-07  8:43 [PATCH net-next v20 00/13] Add Realtek automotive PCIe driver Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 01/13] rtase: Add pci table supported in this module Justin Lai
2024-06-13  9:01   ` Markus Elfring
2024-06-17  8:14     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 02/13] rtase: Implement the .ndo_open function Justin Lai
2024-06-13  7:50   ` Markus Elfring
2024-06-17  9:25     ` Justin Lai
2024-06-17 10:07       ` [v20 " Markus Elfring
2024-06-17 13:28         ` Justin Lai
2024-06-17 18:59           ` Simon Horman
2024-06-17 20:22             ` Markus Elfring
2024-06-18  7:51             ` Justin Lai [this message]
     [not found]             ` <202406181007.45IA7eWxA3305754@rtits1.realtek.com.tw>
2024-06-18 11:01               ` Justin Lai
2024-06-18 11:30                 ` Markus Elfring
2024-06-07  8:43 ` [PATCH net-next v20 03/13] rtase: Implement the rtase_down function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 04/13] rtase: Implement the interrupt routine and rtase_poll Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 05/13] rtase: Implement hardware configuration function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 06/13] rtase: Implement .ndo_start_xmit function Justin Lai
2024-06-07  9:03   ` Hariprasad Kelam
2024-06-12  4:35     ` Justin Lai
2024-06-12 10:36       ` Hariprasad Kelam
2024-06-13  3:38         ` Justin Lai
2024-06-13  7:24           ` Hariprasad Kelam
2024-06-07 15:54   ` Ratheesh Kannoth
2024-06-12  4:20     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 07/13] rtase: Implement a function to receive packets Justin Lai
2024-06-13  0:43   ` Jakub Kicinski
2024-06-17  6:44     ` Justin Lai
2024-06-17 15:02       ` Jakub Kicinski
2024-06-18  3:40         ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 08/13] rtase: Implement net_device_ops Justin Lai
2024-06-13  0:39   ` Jakub Kicinski
2024-06-13  3:16     ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 09/13] rtase: Implement pci_driver suspend and resume function Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 10/13] rtase: Implement ethtool function Justin Lai
2024-06-13  0:35   ` Jakub Kicinski
2024-06-17  6:54     ` Justin Lai
2024-06-17 14:07       ` Andrew Lunn
2024-06-18  9:56         ` Justin Lai
2024-06-17 15:10       ` Jakub Kicinski
2024-06-18  7:28         ` Justin Lai
2024-06-18 14:24           ` Jakub Kicinski
2024-06-19  3:40             ` Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 11/13] rtase: Add a Makefile in the rtase folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 12/13] realtek: Update the Makefile and Kconfig in the realtek folder Justin Lai
2024-06-07  8:43 ` [PATCH net-next v20 13/13] MAINTAINERS: Add the rtase ethernet driver entry Justin Lai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=416da6e14d134caeaa4bfe29291f0eb2@realtek.com \
    --to=justinlai0215@realtek.com \
    --cc=Markus.Elfring@web.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkelam@marvell.com \
    --cc=horms@kernel.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=larry.chiu@realtek.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pkshih@realtek.com \
    --cc=rkannoth@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.