[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <PH0PR18MB4734E8EF622EEA8C81815B32C7BAA@PH0PR18MB4734.namprd18.prod.outlook.com>
Date: Wed, 22 Nov 2023 16:18:44 +0000
From: Shinas Rasheed <srasheed@...vell.com>
To: Jesse Brandeburg <jesse.brandeburg@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Haseeb Gani <hgani@...vell.com>,
Vimlesh Kumar <vimleshk@...vell.com>,
"egallen@...hat.com" <egallen@...hat.com>,
"mschmidt@...hat.com" <mschmidt@...hat.com>,
"pabeni@...hat.com" <pabeni@...hat.com>,
"horms@...nel.org" <horms@...nel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"wizhao@...hat.com" <wizhao@...hat.com>,
"konguyen@...hat.com" <konguyen@...hat.com>,
Veerasenareddy Burru <vburru@...vell.com>,
Sathesh B Edara <sedara@...vell.com>,
Eric Dumazet <edumazet@...gle.com>
Subject: RE: [EXT] Re: [PATCH net-next v1] octeon_ep: get max rx packet length
from firmware
> -----Original Message-----
> From: Jesse Brandeburg <jesse.brandeburg@...el.com>
> Sent: Wednesday, November 22, 2023 2:34 AM
> To: Shinas Rasheed <srasheed@...vell.com>; netdev@...r.kernel.org;
> linux-kernel@...r.kernel.org
> Cc: Haseeb Gani <hgani@...vell.com>; Vimlesh Kumar
> <vimleshk@...vell.com>; egallen@...hat.com; mschmidt@...hat.com;
> pabeni@...hat.com; horms@...nel.org; kuba@...nel.org;
> davem@...emloft.net; wizhao@...hat.com; konguyen@...hat.com;
> Veerasenareddy Burru <vburru@...vell.com>; Sathesh B Edara
> <sedara@...vell.com>; Eric Dumazet <edumazet@...gle.com>
> Subject: [EXT] Re: [PATCH net-next v1] octeon_ep: get max rx packet length
> from firmware
>
> External Email
>
> ----------------------------------------------------------------------
> On 11/21/2023 11:12 AM, Shinas Rasheed wrote:
> > Fill max rx packet length value from firmware.
>
> Hi Shinas, thanks for the patch.
>
> Please provide why, and make sure you're talking to the linux kernel
> developer audience who don't know anything about your hardware. We're
> interested to know why this patch is useful to the kernel and why it
> might need to be applied.
Sure will update that in the changelog in the next version.
> > +/** Get max MTU from firmware.
> > + *
> > + * @param oct: non-null pointer to struct octep_device.
> > + * @param vfid: Index of virtual function.
> > + *
> > + * return value: mtu on success, -errno on failure.
> > + */
>
> The above block is definitely not correctly formatted kdoc (if that's
> what you wanted), and you can probably get feedback about it from
> scripts/kernel-doc -v
> drivers/net/ethernet/marvell/octeon_ep/octep_ctrl_net.h
>
> I see you have some correctly formatted doc in octep_tx.c
I'll see to it to properly format it.
> > diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> > index 3cee69b3ac38..f9c539178114 100644
> > --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> > +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c
> > @@ -1276,6 +1276,7 @@ static int octep_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> > {
> > struct octep_device *octep_dev = NULL;
> > struct net_device *netdev;
> > + int max_rx_pktlen;
> > int err;
> >
> > err = pci_enable_device(pdev);
> > @@ -1346,8 +1347,15 @@ static int octep_probe(struct pci_dev *pdev,
> const struct pci_device_id *ent)
> >
> > netdev->hw_features = NETIF_F_SG;
> > netdev->features |= netdev->hw_features;
> > +
> > + max_rx_pktlen = octep_ctrl_net_get_mtu(octep_dev,
> OCTEP_CTRL_NET_INVALID_VFID);
> > + if (max_rx_pktlen < 0) {
> > + dev_err(&octep_dev->pdev->dev,
> > + "Failed to get max receive packet size; err = %d\n",
> max_rx_pktlen);
> > + goto register_dev_err;
> > + }
> > netdev->min_mtu = OCTEP_MIN_MTU;
> > - netdev->max_mtu = OCTEP_MAX_MTU;
> > + netdev->max_mtu = max_rx_pktlen - (ETH_HLEN + ETH_FCS_LEN);
> > netdev->mtu = OCTEP_DEFAULT_MTU;
>
> Not part of this patch, but was there a point to setting the mtu here
> without telling the netdev? most of the time it seems sufficient to just
> set max and min since the kernel default is already 1500 (which your
> internal define also duplicates)
I suppose that piece of code is redundant, but serves to atleast say that the default expected is 1500 for the device.
Powered by blists - more mailing lists