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: <5317e88a6e334e4db222529287f643ec@realtek.com>
Date: Tue, 20 Aug 2024 05:13:32 +0000
From: Larry Chiu <larry.chiu@...ltek.com>
To: Jakub Kicinski <kuba@...nel.org>, Justin Lai <justinlai0215@...ltek.com>
CC: "davem@...emloft.net" <davem@...emloft.net>,
        "edumazet@...gle.com"
	<edumazet@...gle.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "andrew@...n.ch"
	<andrew@...n.ch>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        "horms@...nel.org"
	<horms@...nel.org>,
        "rkannoth@...vell.com" <rkannoth@...vell.com>,
        "jdamato@...tly.com" <jdamato@...tly.com>,
        Ping-Ke Shih <pkshih@...ltek.com>
Subject: RE: [PATCH net-next v27 07/13] rtase: Implement a function to receive packets



> -----Original Message-----
> From: Jakub Kicinski <kuba@...nel.org>
> Sent: Friday, August 16, 2024 9:55 AM
> To: Justin Lai <justinlai0215@...ltek.com>
> Cc: davem@...emloft.net; edumazet@...gle.com; pabeni@...hat.com;
> linux-kernel@...r.kernel.org; netdev@...r.kernel.org; andrew@...n.ch;
> jiri@...nulli.us; horms@...nel.org; rkannoth@...vell.com;
> jdamato@...tly.com; Ping-Ke Shih <pkshih@...ltek.com>; Larry Chiu
> <larry.chiu@...ltek.com>
> Subject: Re: [PATCH net-next v27 07/13] rtase: Implement a function to
> receive packets
> 
> 
> External mail.
> 
> 
> 
> On Mon, 12 Aug 2024 14:35:33 +0800 Justin Lai wrote:
> > +     if (!delta && workdone)
> > +             netdev_info(dev, "no Rx buffer allocated\n");
> > +
> > +     ring->dirty_idx += delta;
> > +
> > +     if ((ring->dirty_idx + RTASE_NUM_DESC) == ring->cur_idx)
> > +             netdev_emerg(dev, "Rx buffers exhausted\n");
> 
> Memory allocation failures happen, we shouldn't risk spamming the logs.
> I mean these two messages and the one in rtase_alloc_rx_data_buf(),
> the should be removed.
> 
> There is a alloc_fail statistic defined in include/net/netdev_queues.h
> that's the correct way to report buffer allocation failures.

Hi, Jakub,
Can we just count the rx_alloc_fail here?
If we implement the "netdev_stat_ops", we can report this counter.

> And you should have a periodic service task / work which checks for
> buffers being exhausted, and if they are schedule NAPI so that it tries
> to allocate.

We will redefine the rtase_rx_ring_fill() to check the buffers and
try to get page from the pool.
Should we return the budget to schedule this NAPI if there are some
empty buffers?

Thanks,
Larry


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ