| Message ID | 20241107133004.7469-8-shaw.leon@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: Improve netns handling in RTNL and ip_tunnel | expand |
On Thu, 7 Nov 2024 21:30:02 +0800 Xiao Liang wrote: > Since commit 1bf70e6c3a53 ("tools/net/ynl: improve async notification > handling"), check_ntf() would block indefinitely if there's no messages. > In some cases we want to set a limit on waiting time. This patch adds > max_reties parameter check_ntf(), and makes it stop when no message is > recievied in that number of consecutive retries. Looking at 1bf70e6c3a53 again I wonder if we should revert it, sort of, and add its logic back as a new function called poll_nft? The thing is C YNL has check_ntf too - ynl_ntf_check() and it has the old semantics. Would be nice for similarly named functions to behave the same across languages. WDYT Donald? Sorry for not thinking about this earlier. Xiao, feel free to submit this separately from the series.
On Thu, 7 Nov 2024 at 16:04, Jakub Kicinski <kuba@kernel.org> wrote: > > On Thu, 7 Nov 2024 21:30:02 +0800 Xiao Liang wrote: > > Since commit 1bf70e6c3a53 ("tools/net/ynl: improve async notification > > handling"), check_ntf() would block indefinitely if there's no messages. > > In some cases we want to set a limit on waiting time. This patch adds > > max_reties parameter check_ntf(), and makes it stop when no message is > > recievied in that number of consecutive retries. > > Looking at 1bf70e6c3a53 again I wonder if we should revert it, sort of, > and add its logic back as a new function called poll_nft? > > The thing is C YNL has check_ntf too - ynl_ntf_check() and it has the > old semantics. Would be nice for similarly named functions to behave > the same across languages. > > WDYT Donald? Sorry for not thinking about this earlier. Yes, that makes sense. I didn't realise the C lib had an equivalent. Adding a poll_ntf() that calls check_ntf() internally will actually be a bit cleaner overall. It's then a question of whether we need the repeat logic in poll_ntf() because it's always possible to use check_ntf() in your own repeat logic. Either way, I'd prefer not to call the parameter "max_retries" because semantically I don't think we are retrying - it is a count of how many times to repeat the poll. Thoughts? Should it be a "duration" parameter? > Xiao, feel free to submit this separately from the series.
On Fri, Nov 8, 2024 at 1:16 AM Donald Hunter <donald.hunter@gmail.com> wrote: > > It's then a question of whether we need the repeat logic in poll_ntf() > because it's always possible to use check_ntf() in your own repeat > logic. Either way, I'd prefer not to call the parameter "max_retries" > because semantically I don't think we are retrying - it is a count of > how many times to repeat the poll. Thoughts? Should it be a "duration" > parameter? Yes, a "duration" is better. The meaning of "retry" or "count" is not clear. The original check_ntf() is good enough for the test case in this series. Could you make the change, or do you prefer me to submit another patch?
On Fri, 8 Nov 2024 at 08:46, Xiao Liang <shaw.leon@gmail.com> wrote: > > On Fri, Nov 8, 2024 at 1:16 AM Donald Hunter <donald.hunter@gmail.com> wrote: > > > > It's then a question of whether we need the repeat logic in poll_ntf() > > because it's always possible to use check_ntf() in your own repeat > > logic. Either way, I'd prefer not to call the parameter "max_retries" > > because semantically I don't think we are retrying - it is a count of > > how many times to repeat the poll. Thoughts? Should it be a "duration" > > parameter? > > Yes, a "duration" is better. The meaning of "retry" or "count" is not clear. > The original check_ntf() is good enough for the test case in this > series. Could you make the change, or do you prefer me to submit > another patch? I'm happy to make the change. I have prepared a patch which reverts most of 1bf70e6c3a53 and introduces poll_ntf(interval, duration). Jakub, is it okay to submit this as a single patch, or would you prefer me to actually revert 1bf70e6c3a53? (there's about 5 lines retained from the original patch).
On Fri, 8 Nov 2024 at 10:04, Donald Hunter <donald.hunter@gmail.com> wrote: > > Jakub, is it okay to submit this as a single patch, or would you > prefer me to actually revert 1bf70e6c3a53? (there's about 5 lines > retained from the original patch). I'll submit it as a series with a revert and a new patch. The patch is much cleaner that way.
diff --git a/tools/net/ynl/lib/ynl.py b/tools/net/ynl/lib/ynl.py index 92f85698c50e..dff5166a4650 100644 --- a/tools/net/ynl/lib/ynl.py +++ b/tools/net/ynl/lib/ynl.py @@ -907,7 +907,8 @@ class YnlFamily(SpecFamily): msg['msg'] = attrs self.async_msg_queue.put(msg) - def check_ntf(self, interval=0.1): + def check_ntf(self, interval=0.1, max_retries=None): + retry = 0 while True: try: reply = self.sock.recv(self._recv_size, socket.MSG_DONTWAIT) @@ -933,7 +934,11 @@ class YnlFamily(SpecFamily): try: yield self.async_msg_queue.get_nowait() + retry = 0 except queue.Empty: + retry += 1 + if max_retries is not None and retry > max_retries: + return try: time.sleep(interval) except KeyboardInterrupt:
Since commit 1bf70e6c3a53 ("tools/net/ynl: improve async notification handling"), check_ntf() would block indefinitely if there's no messages. In some cases we want to set a limit on waiting time. This patch adds max_reties parameter check_ntf(), and makes it stop when no message is recievied in that number of consecutive retries. Signed-off-by: Xiao Liang <shaw.leon@gmail.com> --- tools/net/ynl/lib/ynl.py | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)