All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: "Seth Forshee (DigitalOcean)" <sforshee@kernel.org>,
	Jay Vosburgh <jv@jvosburgh.net>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Carlos Bilbao <carlos.bilbao@kernel.org>,
	Tonghao Zhang <tonghao@bamaicloud.com>
Subject: Re: [PATCH] bonding: don't force LACPDU tx to ~333 ms boundaries
Date: Tue, 1 Jul 2025 10:10:44 +0200	[thread overview]
Message-ID: <ee862e2c-d268-4530-b3a1-a565640638ff@redhat.com> (raw)
In-Reply-To: <aFwrOs73E03Ifr-i@do-x1carbon>

On 6/25/25 7:00 PM, Seth Forshee (DigitalOcean) wrote:
> On Wed, Jun 25, 2025 at 09:30:56AM -0700, Jay Vosburgh wrote:
>> Seth Forshee (DigitalOcean) <sforshee@kernel.org> wrote:
>>
>>> The timer which ensures that no more than 3 LACPDUs are transmitted in
>>> a second rearms itself every 333ms regardless of whether an LACPDU is
>>> transmitted when the timer expires. This causes LACPDU tx to be delayed
>>> until the next expiration of the timer, which effectively aligns LACPDUs
>>> to ~333ms boundaries. This results in a variable amount of jitter in the
>>> timing of periodic LACPDUs.
>>
>> 	To be clear, the "3 per second" limitation that all of this
>> should to conform to is from IEEE 802.1AX-2014, 6.4.16 Transmit machine:
>>
>> 	"When the LACP_Enabled variable is TRUE and the NTT (6.4.7)
>> 	variable is TRUE, the Transmit machine shall ensure that a
>> 	properly formatted LACPDU (6.4.2) is transmitted [i.e., issue a
>> 	CtrlMuxN:M_UNITDATA.Request(LACPDU) service primitive], subject
>> 	to the restriction that no more than three LACPDUs may be
>> 	transmitted in any Fast_Periodic_Time interval. If NTT is set to
>> 	TRUE when this limit is in force, the transmission shall be
>> 	delayed until such a time as the restriction is no longer in
>> 	force. The NTT variable shall be set to FALSE when the Transmit
>> 	machine has transmitted a LACPDU."
>>
>> 	The current implementation conforms to this as you describe: by
>> aligning transmission to 1/3 second boundaries, no more than 3 can ever
>> be sent in one second.
>>
>> 	If, hypothetically, the state machine were to transition, or a
>> user updates port settings (either of which would set NTT each time)
>> more than 3 times in a second, would your patched code obey this
>> restriction?
> 
> As long as the transition doesn't reset sm_tx_timer_counter to something
> smaller than ad_ticks_per_sec/AD_MAX_TX_IN_SECOND, which nothing does
> currently (and if it did it would be at risk of sending more than 3 in a
> second already). The timer is reset on each tx, so no two consecutive
> LACPDUs can be sent less than 300ms apart, therefore no more than 3 can
> be per second. If a state machine transition sets NTT within 300ms of
> the previous tx, it will not send another until the timer expires.

@Jay, I believe the above statement is correct. What I'm missing?

Side note: I'm wondering if this should be considered a fix, and thus
requiring targeting the 'net' tree and a 'fixes' tag.

/P


  reply	other threads:[~2025-07-01  8:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25 16:01 [PATCH] bonding: don't force LACPDU tx to ~333 ms boundaries Seth Forshee (DigitalOcean)
2025-06-25 16:13 ` Carlos Bilbao
2025-06-25 16:30 ` Jay Vosburgh
2025-06-25 17:00   ` Seth Forshee (DigitalOcean)
2025-07-01  8:10     ` Paolo Abeni [this message]
2025-07-03 13:30 ` patchwork-bot+netdevbpf

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=ee862e2c-d268-4530-b3a1-a565640638ff@redhat.com \
    --to=pabeni@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=carlos.bilbao@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jv@jvosburgh.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sforshee@kernel.org \
    --cc=tonghao@bamaicloud.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.