Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-07 Thread David Marchand
On Tue, Oct 8, 2024 at 4:09 AM lihuisong (C) wrote: > > > 在 2024/10/2 23:57, David Marchand 写道: > > While invoking telemetry commands (which may happen at any time, > > out of control of the application), an application thread may > > concurrently add/remove ports. > > The telemetry callbacks may

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-07 Thread lihuisong (C)
在 2024/10/2 23:57, David Marchand 写道: While invoking telemetry commands (which may happen at any time, out of control of the application), an application thread may concurrently add/remove ports. The telemetry callbacks may then access partially initialised/uninitialised ethdev data. Reuse the

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-03 Thread David Marchand
On Thu, Oct 3, 2024 at 11:46 AM Bruce Richardson wrote: > > On Wed, Oct 02, 2024 at 09:26:10PM +0200, Robin Jarry wrote: > > David Marchand, Oct 02, 2024 at 21:18: > > > On Wed, Oct 2, 2024 at 9:09 PM Robin Jarry wrote: > > > > I was going to suggest adding a rte_spinlock_t* parameter to a new >

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-03 Thread Bruce Richardson
On Wed, Oct 02, 2024 at 09:26:10PM +0200, Robin Jarry wrote: > David Marchand, Oct 02, 2024 at 21:18: > > On Wed, Oct 2, 2024 at 9:09 PM Robin Jarry wrote: > > > I was going to suggest adding a rte_spinlock_t* parameter to a new > > > telemetry register function that would need to be held while th

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread Robin Jarry
David Marchand, Oct 02, 2024 at 21:18: On Wed, Oct 2, 2024 at 9:09 PM Robin Jarry wrote: I was going to suggest adding a rte_spinlock_t* parameter to a new telemetry register function that would need to be held while the callback is invoked. Or if we want to keep doors open to other kinds of lo

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread David Marchand
On Wed, Oct 2, 2024 at 9:09 PM Robin Jarry wrote: > >> An alternative to this macro-fu, is to just define a single ethdev > >> telemetry function, and within that, take the lock and then dispatch to the > >> appropriate subfunction based upon the actual command coming in. The > >> dispatch may be

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread Robin Jarry
David Marchand, Oct 02, 2024 at 21:06: On Wed, Oct 2, 2024 at 6:27 PM Bruce Richardson wrote: On Wed, Oct 02, 2024 at 05:57:08PM +0200, David Marchand wrote: > While invoking telemetry commands (which may happen at any time, > out of control of the application), an application thread may > con

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread David Marchand
On Wed, Oct 2, 2024 at 6:27 PM Bruce Richardson wrote: > > On Wed, Oct 02, 2024 at 05:57:08PM +0200, David Marchand wrote: > > While invoking telemetry commands (which may happen at any time, > > out of control of the application), an application thread may > > concurrently add/remove ports. > > T

Re: [PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread Bruce Richardson
On Wed, Oct 02, 2024 at 05:57:08PM +0200, David Marchand wrote: > While invoking telemetry commands (which may happen at any time, > out of control of the application), an application thread may > concurrently add/remove ports. > The telemetry callbacks may then access partially > initialised/unini

[PATCH 2/2] ethdev: fix race on ports for telemetry commands

2024-10-02 Thread David Marchand
While invoking telemetry commands (which may happen at any time, out of control of the application), an application thread may concurrently add/remove ports. The telemetry callbacks may then access partially initialised/uninitialised ethdev data. Reuse the ethdev lock that protects port allocation