netdev - RE: [EXT] Re: [net PATCH V3 2/3] octeontx2-af: CN10KB: fix PFC configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: 
 <SJ0PR18MB5216B17C79050D97B5D6D9EDDB1CA@SJ0PR18MB5216.namprd18.prod.outlook.com>
Date: Wed, 23 Aug 2023 13:16:49 +0000
From: Suman Ghosh <sumang@...vell.com>
To: Simon Horman <horms@...nel.org>, Paolo Abeni <pabeni@...hat.com>
CC: Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        Geethasowjanya Akula
	<gakula@...vell.com>,
        Subbaraya Sundeep Bhatta <sbhatta@...vell.com>,
        Hariprasad Kelam <hkelam@...vell.com>,
        Linu Cherian <lcherian@...vell.com>,
        Jerin Jacob Kollanukkaran <jerinj@...vell.com>,
        "davem@...emloft.net"
	<davem@...emloft.net>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [net PATCH V3 2/3] octeontx2-af: CN10KB: fix PFC
 configuration

>----------------------------------------------------------------------
>On Tue, Aug 22, 2023 at 01:12:26PM +0200, Paolo Abeni wrote:
>> On Tue, 2023-08-22 at 09:16 +0200, Simon Horman wrote:
>> > On Mon, Aug 21, 2023 at 10:55:15AM +0530, Suman Ghosh wrote:
>> > > From: Hariprasad Kelam <hkelam@...vell.com>
>> > >
>> > > The previous patch which added new CN10KB RPM block support, has a
>> > > bug due to which PFC is not getting configured properly.
>> > > This patch fixes the same.
>> >
>> > Hi Suman,
>> >
>> > I think it would be useful to describe what the bug is - it seems
>> > like an incorrect mask in some cases - and how that might affect
>> > users. Better still would be commands for an example usage where the
>> > problem previously manifested.
>>
>> Suman, please address Simon's feedback above in the new iteration.
[Suman] Sure. I will update in V4
>>
>> > >
>> > > Fixes: 99c969a83d82 ("octeontx2-pf: Add egress PFC support")
>> > > Signed-off-by: Hariprasad Kelam <hkelam@...vell.com>
>> > > ---
>> > >  drivers/net/ethernet/marvell/octeontx2/af/rpm.c | 17
>> > > +++++++++--------
>> > >  1 file changed, 9 insertions(+), 8 deletions(-)
>> > >
>> > > diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rpm.c
>> > > b/drivers/net/ethernet/marvell/octeontx2/af/rpm.c
>> > > index b4fcb20c3f4f..af21e2030cff 100644
>> > > --- a/drivers/net/ethernet/marvell/octeontx2/af/rpm.c
>> > > +++ b/drivers/net/ethernet/marvell/octeontx2/af/rpm.c
>> > > @@ -355,8 +355,8 @@ int rpm_lmac_enadis_pause_frm(void *rpmd, int
>> > > lmac_id, u8 tx_pause,
>> > >
>> > >  void rpm_lmac_pause_frm_config(void *rpmd, int lmac_id, bool
>> > > enable)  {
>> > > +	u64 cfg, pfc_class_mask_cfg;
>> > >  	rpm_t *rpm = rpmd;
>> > > -	u64 cfg;
>> > >
>> > >  	/* ALL pause frames received are completely ignored */
>> > >  	cfg = rpm_read(rpm, lmac_id, RPMX_MTI_MAC100X_COMMAND_CONFIG);
>> > > @@ -380,9 +380,11 @@ void rpm_lmac_pause_frm_config(void *rpmd,
>int lmac_id, bool enable)
>> > >  		rpm_write(rpm, 0, RPMX_CMR_CHAN_MSK_OR, ~0ULL);
>> > >
>> > >  	/* Disable all PFC classes */
>> > > -	cfg = rpm_read(rpm, lmac_id, RPMX_CMRX_PRT_CBFC_CTL);
>> > > +	pfc_class_mask_cfg = is_dev_rpm2(rpm) ? RPM2_CMRX_PRT_CBFC_CTL
>:
>> > > +						RPMX_CMRX_PRT_CBFC_CTL;
>> >
>> > Maybe it is overkill, but as this appears at least twice, perhaps a
>> > helper would be appropriate.
>>
>> I think this is a matter of personal preferences (there is another
>> similar chunk with will not fit an helper, short of implementing it
>> with a somewhat ugly macro. So the overall code would be asymmetric),
>>
>> I'm fine either way.
>
>Likewise, I don't feel strongly either way.
[Suman] Then, I would like to keep it as is. I can consider macro/function if we are using more of it in future.