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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 14 Jan 2022 11:28:35 +0530 From: sundeep subbaraya <sundeep.lkml@...il.com> To: Jakub Kicinski <kuba@...nel.org> Cc: Subbaraya Sundeep <sbhatta@...vell.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org, hariprasad <hkelam@...vell.com>, Geetha sowjanya <gakula@...vell.com>, Sunil Kovvuri Goutham <sgoutham@...vell.com> Subject: Re: [net-next PATCH] octeontx2-pf: Change receive buffer size using ethtool Hi Jakub, On Fri, Jan 14, 2022 at 12:01 AM Jakub Kicinski <kuba@...nel.org> wrote: > > On Thu, 13 Jan 2022 12:07:42 +0530 sundeep subbaraya wrote: > > > Should we use rx_buf_len = 0 as a way for users to reset the rxbuf len > > > to the default value? I think that would be handy. > > > > > Before this patch we calculate each receive buffer based on mtu set by user. > > Now user can use rx-buf-len but the old mtu based calculation is also there. > > Here I am using rx_buf_len == 0 as a switch to calculate buffer length > > using mtu or > > just use length set by user. So here I am not setting rx_buf_len to some > > default value. > > > > > > --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c > > > > +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c > > > > @@ -66,6 +66,8 @@ static int otx2_change_mtu(struct net_device *netdev, int new_mtu) > > > > netdev->mtu, new_mtu); > > > > netdev->mtu = new_mtu; > > > > > > > > + pf->hw.rbuf_len = 0; > > > > > > Why reset the buf len on mtu change? > > > > > As explained above buffer size will be calculated using mtu > > now instead of rx-buf-len from ethtool. > > IIUC you're saying that the way to get back to the default buffer size > is to change the MTU? > > It was discussed on the list in the past in the context of RSS > indirection tables and the conclusion was that we should not reset > explicit user configuration (in case of RSS indir table this means > user-set table survives change in the number of queues). > > Having one config reset another is pretty painful to deal with for > the users. I had to fix many cases of this sort of problem in the > production env I'm working with. Turning one knob resets other knobs > so it takes multiple runs of the config daemon (chef or alike) to > get to the target configuration. > > In my mind if user has set the rx-buf-len it should survive all other > config changes. User can reset to default by setting rx-buf-len to 0. > It should be possible to set rx-buf-len and mtu in any order and have > the same result. Thanks for the clear explanation. I will change as per your comments and send the next spin. Sundeep
Powered by blists - more mailing lists