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
11 matches
Mail list logo
