On Mon, Apr 3, 2023 at 5:37 PM Tyler Retzlaff
<roret...@linux.microsoft.com> wrote:
>
> On Mon, Apr 03, 2023 at 12:52:06PM +0200, David Marchand wrote:
> > Hello Tyler,
> >
> > On Thu, Mar 2, 2023 at 9:52 AM David Marchand <david.march...@redhat.com>
> > wrote:
> > > On Mon, Feb 27, 2023 at 5:13 PM Gaëtan Rivet <gr...@u256.net> wrote:
> > > > Ah ok, so if I understand correctly, DPDK would need to declare some
> > > > '__rte_lockable rte_mutex' and associated functions for transparent
> > > > support,
> > > > to wrap above the pthread API.
> > >
> > > Yes, this is what I had in mind for the mid/long term but it was too
> > > late for 23.03 after -rc1.
> > >
> > > The Windows porting effort will probably need this abstraction too as
> > > we are trying to stop relying on the pthread API.
> > > I don't see this item in Microsoft roadmap, though.
> >
> > Do you have an opinion on this topic?
>
> Okay, trying to grok the question here. If the question is do we want to
> introduce a mutex/condition variable and lock/unlock signal/wait
> abstraction?
>
> I would certainly like to see reduced conditional compilation that
> applications have to perform for the platform features. I also really
> would like to purge the remaining pthread_{mutex,condvar} shim since it
> is unsightly.
>
> With msvc I think we could probably achieve the same with C11 threads but
> I haven't investigated feasability and said with no investigation older
> glibc may not provide the optional feature.
>
> In the absence of C11 threads we can provide an rte_ abstraction but I
> don't think I can put it on the roadmap until basic msvc support is
> stood up (a question of resource prioritization as always).
>
> I could commit to looking at it once msvc and atomics changes are merged
> the earliest possible time frame for that is the start of the 23.11
> cycle. If that happens at decent velocity I could even see adding it to
> 23.11 roadmap.
Ok for me.
>
> For now if someone else decides to introduce an abstraction I would just
> caution strongly not to remove __rte_experimental from any API added
> until I get a chance to focus on it.
We *could* introduce an internal API.
But I prefer we wait for your input on this topic rather than
introduce some artificial API.
I'll simply disable those checks on FreeBSD.
--
David Marchand
