Thanks Josh. That greatly makes my life easier.
On Tue, 29 May 2018, 13:28 Josh Bailey, <joshb(a)google.com> wrote:
To address your immediate point, I've now
automatically enabled LLDP
processing on stacking ports, and LLDP probes on stacking ports are not
subject to outbound rate limiting.
There will be future work to refactor to handle the general case of
keeping the OF channel load managed.
On Sun, May 27, 2018 at 6:12 PM Josh Bailey <joshb(a)google.com> wrote:
> That's a good point, stacking ports should send advertisements as a
> priority in their own thread.
> Regarding a thread per port. This pattern will result in a heck of a lot
> of threads. I'm also wary of guaranteeing transmission at specific times -
> being cooperatively scheduled such a guarantee is not practical, and we
> should not create batches of packets that can accumulate in the controller
> (or in the OFA) which will cause the OF channel to get bursty. Probably one
> thread that does less work, more often is a better approach.
> On Sun, May 27, 2018 at 1:26 AM Truong Huu Trung <trungdtbk(a)gmail.com>
>> We use send_interval to select which ports (selected randomly) to send
>> out LLDP at a time interval.
>> The time interval (at which the EventFaucetLLDPAdvertise is fired) is
>> hardcoded 5 sec + 2 sec jitters.
>> If send_interval is set < event interval, then previously selected ports
>> will have chance to be selected again.
>> Also, the interval of LLDP packets per port is non-deterministic.
>> I'm implementing the stack probing, I see that this non-determination
>> can result in instability (we mistake this for packet loss).
>> I'm suggesting to fire LLDP advertise event per port basis. We create a
>> thread for each port, which fires the event LLDPAdvertise(port_no).
>> That allows us to spread the workload while maintaining a more precise
>> sending interval per port.
>> Faucet-dev mailing list