[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4ec02430-e1e1-4180-857b-14c4591e7d87@openvpn.net>
Date: Fri, 19 Jul 2024 10:59:23 +0200
From: Antonio Quartulli <antonio@...nvpn.net>
To: Andrew Lunn <andrew@...n.ch>
Cc: Sabrina Dubroca <sd@...asysnail.net>, netdev@...r.kernel.org,
kuba@...nel.org, ryazanov.s.a@...il.com, pabeni@...hat.com,
edumazet@...gle.com
Subject: Re: [PATCH net-next v5 17/25] ovpn: implement keepalive mechanism
On 19/07/2024 05:31, Andrew Lunn wrote:
> On Thu, Jul 18, 2024 at 09:46:00AM +0200, Antonio Quartulli wrote:
>> On 18/07/2024 04:01, Andrew Lunn wrote:
>>>>>> + if (ovpn_is_keepalive(skb)) {
>>>>>> + netdev_dbg(peer->ovpn->dev,
>>>>>> + "ping received from peer %u\n", peer->id);
>>>>>
>>>>> That should probably be _ratelimited, but it seems we don't have
>>>>> _ratelimited variants for the netdev_* helpers.
>>>>
>>>> Right.
>>>> I have used the net_*_ratelimited() variants when needed.
>>>> Too bad we don't have those.
>>>
>>> If you think netdev_dbg_ratelimited() would be useful, i don't see why
>>> you cannot add it.
>>>
>>> I just did an search and found something interesting in the history:
>>>
>>> https://lore.kernel.org/all/20190809002941.15341-1-liuhangbin@gmail.com/T/#u
>>>
>>> Maybe limit it to netdev_dbg_ratelimited() to avoid the potential
>>> abuse DaveM was worried about.
>>
>> I see what Dave says however...
>>
>> ...along the packet processing routine there are several messages (some are
>> err or warn or info) which require ratelimiting.
>> Otherwise you end up with a gazilion log entries in case of a long lasting
>> issue.
>>
>> Right now I am using net_dbg/warn/err/info_ratelimited(), therefore not
>> having a netdev counterpart is not really helping with Dave's argument.
>
> Yes, i think Dave' argument is weak because these alternatives
> exist. Maybe they did not at the time?
They did and it's exactly what Hangbin was introducing:
https://lore.kernel.org/all/20190801090347.8258-1-liuhangbin@gmail.com/
before being suggested by Joe to implement the new macros:
https://lore.kernel.org/all/209f7fe62e2a79cd8c02b104b8e3babdd16bff30.camel@perches.com/
>
> I suspect he was using it as a way to force fixing the real issue. A
> driver should not be issues lots of err or info messages. Protocol
> errors are part of normal behaviour, just increment a counter and keep
> going. Peer devices disappearing is normal behaviour, count it and
> keep going. _err is generally reserved for something fatal happened,
> and there is no recovery, other than unload the kernel module and
> reload it.
Yeah, it looks like it and David pushed them to rethink the error
handling rather than making the error less painful.
But I can still netdev_dbg_ratelimited useful for debugging/development.
Anyway, I will add this to my todo and see if this specific variant can
be accepted.
Regards,
--
Antonio Quartulli
OpenVPN Inc.
Powered by blists - more mailing lists