On 2024-12-16 10:49, David Marchand wrote:
On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly
wrote:
On 12/5/2024 6:57 PM, David Marchand wrote:
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications does no
On Mon, Dec 16, 2024 at 10:49 AM David Marchand
wrote:
> > > For now, this series only focus on fixing subsystems using lcore
> > > variables so that those allocations are deferred either in rte_eal_init()
> > > or in the path that does require such lcore variables.
> > >
> > >
> >
> > An idle que
On 12/10/2024 10:41 AM, Mattias Rönnblom wrote:
Maybe the DAG is available on the build (meson) level, and thus the code
can be generated out of that?
There is in fact a patchset that produces just that kind of graph:
https://patches.dpdk.org/project/dpdk/list/?series=34055
It's currentl
On Mon, Dec 16, 2024 at 10:42 AM Burakov, Anatoly
wrote:
>
> On 12/5/2024 6:57 PM, David Marchand wrote:
> > As I had reported in rc2, the lcore variables allocation have a
> > noticeable impact on applications consuming DPDK, even when such
> > applications does not use DPDK, or use features asso
On 12/5/2024 6:57 PM, David Marchand wrote:
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications does not use DPDK, or use features associated to
some lcore variables.
While the amount has been reduced in a
On Fri, 06 Dec 2024 16:55:30 +0100
Thomas Monjalon wrote:
> 06/12/2024 12:01, Mattias Rönnblom:
> > On 2024-12-05 18:57, David Marchand wrote:
> > In retrospect, maybe the offset between lcore variable instances could
> > have been encoded into the handle, and thus one could use
> > different-s
On 2024-12-09 18:40, David Marchand wrote:
On Mon, Dec 9, 2024 at 4:39 PM Mattias Rönnblom wrote:
On 2024-12-09 12:03, David Marchand wrote:
On Fri, Dec 6, 2024 at 12:02 PM Mattias Rönnblom wrote:
On 2024-12-05 18:57, David Marchand wrote:
As I had reported in rc2, the lcore variables alloc
On Mon, Dec 9, 2024 at 4:39 PM Mattias Rönnblom wrote:
> On 2024-12-09 12:03, David Marchand wrote:
> > On Fri, Dec 6, 2024 at 12:02 PM Mattias Rönnblom
> > wrote:
> >> On 2024-12-05 18:57, David Marchand wrote:
> >>> As I had reported in rc2, the lcore variables allocation have a
> >>> noticeab
On 2024-12-09 12:03, David Marchand wrote:
Hello,
On Fri, Dec 6, 2024 at 12:02 PM Mattias Rönnblom wrote:
On 2024-12-05 18:57, David Marchand wrote:
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications d
Hello,
On Fri, Dec 6, 2024 at 12:02 PM Mattias Rönnblom wrote:
>
> On 2024-12-05 18:57, David Marchand wrote:
> > As I had reported in rc2, the lcore variables allocation have a
> > noticeable impact on applications consuming DPDK, even when such
> > applications does not use DPDK, or use feature
06/12/2024 12:01, Mattias Rönnblom:
> On 2024-12-05 18:57, David Marchand wrote:
> In retrospect, maybe the offset between lcore variable instances could
> have been encoded into the handle, and thus one could use
> different-sized offset for different variables.
Yes it would allow to allocate a
On 2024-12-05 18:57, David Marchand wrote:
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications does not use DPDK, or use features associated to
some lcore variables.
While the amount has been reduced in a r
As I had reported in rc2, the lcore variables allocation have a
noticeable impact on applications consuming DPDK, even when such
applications does not use DPDK, or use features associated to
some lcore variables.
While the amount has been reduced in a rush before rc2,
there are still cases when th
13 matches
Mail list logo
