[dpdk-dev] [PATCH 1/2] net/octeontx: add channel to port id mapping

Ferruh Yigit ferruh.yigit at intel.com
Fri Dec 8 18:39:00 CET 2017


On 12/8/2017 3:08 AM, Pavan Nikhilesh Bhagavatula wrote:
> On Thu, Dec 07, 2017 at 04:41:04PM -0800, Ferruh Yigit wrote:
>> On 11/28/2017 6:58 AM, Pavan Nikhilesh wrote:
>>> The channel to port id map is used by event octeontx to map the received
>>> wqe to the respective ethdev port.
>>>
>>> Signed-off-by: Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>
>>
>> <...>
>>
>>> @@ -52,12 +52,18 @@
>>>  #define OCTEONTX_VDEV_NR_PORT_ARG		("nr_port")
>>>  #define OCTEONTX_MAX_NAME_LEN			32
>>>
>>> +#define OCTEONTX_MAX_BGX_PORTS			4
>>> +#define OCTEONTX_MAX_LMAC_PER_BGX		4
>>> +
>>>  static inline struct octeontx_nic *
>>>  octeontx_pmd_priv(struct rte_eth_dev *dev)
>>>  {
>>>  	return dev->data->dev_private;
>>>  }
>>>
>>> +uint16_t __rte_cache_aligned
>>> +octeontx_pchan_map[OCTEONTX_MAX_BGX_PORTS][OCTEONTX_MAX_LMAC_PER_BGX];
>>
>> defining global variable in header is generally not good a idea, is there a
>> reason why not variable defined in octeontx_ethdev.c and exported here, so that
>> both octeontx ethdev and eventdev can use it?
> 
> The reason extern definition in .h and declaration in .c is not done is that
> it would break shared compilation.

This should work, you can put object into .so and access from application and/or
other shared libraries. I did a quick test, and seems working, is there anything
I am missing.

> The other approach is to do it in  octeontx_mempool area but it wouldnt make
> sense.
> I could use the mempool approach if it sounds good to you (or) let me know
> if any alternate approach comes to your mind.
> 
>>
>> btw, is build time dependency between octeontx ethdev and eventdev documented
>> somewhere?
> 
> Currently, there is no build time dependency between event_octeontx and
> eth_octeontx i.e everything builds fine with CONFIG_RTE_LIBRTE_OCTEONTX_PMD=n.

octeontx eventdev is using a variable from octeontx ethdev header, how can be
there is no build time dependency?

> 
> Thanks,
> Pavan
> 



More information about the dev mailing list