On Mon, Mar 25, 2024 at 9:21 PM Robin Jarry wrote:
>
> Jerin Jacob, Mar 25, 2024 at 16:47:
> > > #define RTE_NODE_CTX_PTR1(n) ((void **)(n)->ctx)[0]
> > > #define RTE_NODE_CTX_PTR2(n) ((void **)(n)->ctx)[1]
> >
> > Works for me. No strong opinion about the name, RTE_NODE_CTX_AS_PTR1
> > may be mor
Jerin Jacob, Mar 25, 2024 at 16:47:
> #define RTE_NODE_CTX_PTR1(n) ((void **)(n)->ctx)[0]
> #define RTE_NODE_CTX_PTR2(n) ((void **)(n)->ctx)[1]
Works for me. No strong opinion about the name, RTE_NODE_CTX_AS_PTR1
may be more reflecting the intent.
I also thought about adding inline getter/sett
On Mon, Mar 25, 2024 at 8:50 PM Robin Jarry wrote:
>
> Jerin Jacob, Mar 25, 2024 at 12:35:
> > Another option could be to have a helper inline function/macro to take
> > care of casting to make app code clean of casting.
>
> Would something like this be suitable?
>
> #define RTE_NODE_CTX_PTR1(n) (
Jerin Jacob, Mar 25, 2024 at 12:35:
Another option could be to have a helper inline function/macro to take
care of casting to make app code clean of casting.
Would something like this be suitable?
#define RTE_NODE_CTX_PTR1(n) ((void **)(n)->ctx)[0]
#define RTE_NODE_CTX_PTR2(n) ((void **)(n)->c
On Mon, Mar 25, 2024 at 12:35 PM Jerin Jacob wrote:
>
> On Mon, Mar 25, 2024 at 4:45 PM Robin Jarry wrote:
> >
> > Jerin Jacob, Mar 25, 2024 at 12:08:
> > > > It will not be taken into account for MSVC. Is that OK?
> > >
> > > Why?. rte_mbuf has a similar scheme.
> > > RTE_MARKER cacheline1 __rte
On Mon, Mar 25, 2024 at 05:05:12PM +0530, Jerin Jacob wrote:
> On Mon, Mar 25, 2024 at 4:45 PM Robin Jarry wrote:
> >
> > Jerin Jacob, Mar 25, 2024 at 12:08:
> > > > It will not be taken into account for MSVC. Is that OK?
> > >
> > > Why?. rte_mbuf has a similar scheme.
> > > RTE_MARKER cacheline1
On Mon, Mar 25, 2024 at 4:45 PM Robin Jarry wrote:
>
> Jerin Jacob, Mar 25, 2024 at 12:08:
> > > It will not be taken into account for MSVC. Is that OK?
> >
> > Why?. rte_mbuf has a similar scheme.
> > RTE_MARKER cacheline1 __rte_cache_min_aligned;
>
> RTE_MARKER* types seem not defined for the MS
Jerin Jacob, Mar 25, 2024 at 12:08:
> It will not be taken into account for MSVC. Is that OK?
Why?. rte_mbuf has a similar scheme.
RTE_MARKER cacheline1 __rte_cache_min_aligned;
RTE_MARKER* types seem not defined for the MSVC toolchain.
https://github.com/DPDK/dpdk/blob/v24.03-rc4/lib/eal/inc
On Mon, Mar 25, 2024 at 4:32 PM Robin Jarry wrote:
>
> Jerin Jacob, Mar 25, 2024 at 11:59:
> > > +static_assert(offsetof(struct rte_node, ctx) % RTE_CACHE_LINE_SIZE == 0,
> > > + "rte_node ctx must be aligned on a cache line");
> >
> >
> > This will fail in 32bit machine.
> > https://mails.d
Jerin Jacob, Mar 25, 2024 at 11:59:
> +static_assert(offsetof(struct rte_node, ctx) % RTE_CACHE_LINE_SIZE == 0,
> + "rte_node ctx must be aligned on a cache line");
This will fail in 32bit machine.
https://mails.dpdk.org/archives/test-report/2024-March/623806.html
Hi Jerin, yes I saw th
On Mon, Mar 25, 2024 at 3:35 PM Robin Jarry wrote:
>
> In some cases, the node context data is used to store two pointers
> because the data is larger than the reserved 16 bytes. Having to define
> intermediate structures just to be able to cast is tedious. Add two
> pointers that take the same sp
In some cases, the node context data is used to store two pointers
because the data is larger than the reserved 16 bytes. Having to define
intermediate structures just to be able to cast is tedious. Add two
pointers that take the same space than ctx.
Signed-off-by: Robin Jarry
---
Notes:
v3:
12 matches
Mail list logo
