On 4/10/20 7:09 AM, Nithin Dabilpuram wrote:
> On Fri, Apr 10, 2020 at 01:07:17AM +0200, Andrzej Ostruszka wrote:
[...]
>>> +struct rte_node_mbuf_priv2 {
>>> + union {
>>> + /* Sym crypto */
>>> + struct {
>>> + struct rte_crypto_op op;
>>> + };
>>> + };
>>> +} __rte_cache_aligned;
>>
>> Why such definition?
The question was more on "technicalities" - you have struct with anon
union with anon struct with a struct. Why such deep nesting - I guess
the union is there for the possible future extensions but the next anon
struct - what is it for?
> For communication b/w nodes, we need some per mbuf private space.
> We defined it into two halfs for performance reasons as
> #1 rte_node_mbuf_priv1(8 bytes) mapped to mbuf->udata64
> #2 rte_node_mbuf_priv2(RTE_CACHE_LINE_SIZE bytes) mapped to mbuf private area.
>
> #1 is smaller area and will not have a cache miss when accessed as mbuf
> is already in cache.
> #2 is larger area and probably good enough for many use cases like ipsec,
> crypto
> etc, and there will be an extra cost of cache miss to access it.
>
> Atleast in OCTEONTX2, we are able to see 27% performance drop, if use single
> private area #2 for everything instead.
>
> Since pkt_mbuf pool are created by application, we these structures are
> defined
> here have a check in ctrl api if the pkt_mbuf pool meets the mbuf private area
> size requirement.
Thank you for explanations.
With regards
Andrzej Ostruszka
