From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, Jonathan Toppins <jtoppins@redhat.com>,
Veaceslav Falico <vfalico@gmail.com>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: [PATCH net] veth: Add updating of trans_start
Date: Fri, 17 Jun 2022 09:42:55 -0700 [thread overview]
Message-ID: <5765.1655484175@famine> (raw)
In-Reply-To: <20220617084535.6d687ed0@kernel.org>
Jakub Kicinski <kuba@kernel.org> wrote:
>On Thu, 16 Jun 2022 12:26:30 -0700 Jay Vosburgh wrote:
>> Since commit 21a75f0915dd ("bonding: Fix ARP monitor validation"),
>> the bonding ARP / ND link monitors depend on the trans_start time to
>> determine link availability. NETIF_F_LLTX drivers must update trans_start
>> directly, which veth does not do. This prevents use of the ARP or ND link
>> monitors with veth interfaces in a bond.
>
>Why is a SW device required to update its trans_start? trans_start is
>for the Tx hang watchdog, AFAIK, not a general use attribute. There's
>plenty of NETIF_F_LLTX devices, are they all broken?
In this case, it's to permit the bonding ARP / ND monitor to
function if that software device (veth in this case) is added to a bond
using the ARP / ND monitor (which relies on trans_start, and has done so
since at least 2.6.0). I'll agree it's a niche case; this was broken
for veth for quite some time, but veth + netns is handy for software
only test cases, so it seems worth doing.
I didn't exhaustively check all LLTX drivers, but, e.g., tun
does update trans_start:
drivers/net/tun.c:
/* NETIF_F_LLTX requires to do our own update of trans_start */
queue = netdev_get_tx_queue(dev, txq);
txq_trans_cond_update(queue);
-J
---
-Jay Vosburgh, jay.vosburgh@canonical.com
next prev parent reply other threads:[~2022-06-17 16:43 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-16 19:26 [PATCH net] veth: Add updating of trans_start Jay Vosburgh
2022-06-17 10:40 ` patchwork-bot+netdevbpf
2022-06-17 15:45 ` Jakub Kicinski
2022-06-17 16:42 ` Jay Vosburgh [this message]
2022-06-17 19:44 ` Jakub Kicinski
2022-06-18 0:27 ` Jay Vosburgh
2022-06-18 0:55 ` Jakub Kicinski
2022-06-21 19:52 ` Jakub Kicinski
2022-06-22 1:42 ` Jay Vosburgh
2022-06-22 4:38 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5765.1655484175@famine \
--to=jay.vosburgh@canonical.com \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=jtoppins@redhat.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vfalico@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.