[dpdk-dev] [PATCH 1/6] ethdev: add an field for querying hash key size

[Neil Horman]

On Fri, Jun 05, 2015 at 06:21:52AM +0000, Zhang, Helin wrote:
> Hi Neil
> 
> Yes, thank you very much for the comments!
> I realized the ABI issue after I sent out the patch. I think even I put the new one the end of this structure, it may also have issue.
> I'd like to have this change announced and then get it merged. That means I'd like to make this change and follow the policy and process.
> 
> Regards,
> Helin
> 

Ok, sounds good.

Thanks!
Neil

> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > Sent: Thursday, June 4, 2015 9:05 PM
> > To: Zhang, Helin
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH 1/6] ethdev: add an field for querying hash key
> > size
> > 
> > On Thu, Jun 04, 2015 at 09:00:33AM +0800, Helin Zhang wrote:
> > > To support querying hash key size per port, an new field of
> > > 'hash_key_size' was added in 'struct rte_eth_dev_info' for storing
> > > hash key size in bytes.
> > >
> > > Signed-off-by: Helin Zhang <helin.zhang at intel.com>
> > > ---
> > >  lib/librte_ether/rte_ethdev.h | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/lib/librte_ether/rte_ethdev.h
> > > b/lib/librte_ether/rte_ethdev.h index 16dbe00..004b05a 100644
> > > --- a/lib/librte_ether/rte_ethdev.h
> > > +++ b/lib/librte_ether/rte_ethdev.h
> > > @@ -916,6 +916,7 @@ struct rte_eth_dev_info {
> > >  	uint16_t max_vmdq_pools; /**< Maximum number of VMDq pools. */
> > >  	uint32_t rx_offload_capa; /**< Device RX offload capabilities. */
> > >  	uint32_t tx_offload_capa; /**< Device TX offload capabilities. */
> > > +	uint8_t hash_key_size; /**< Hash key size in bytes */
> > >  	uint16_t reta_size;
> > >  	/**< Device redirection table size, the total number of entries. */
> > >  	/** Bit mask of RSS offloads, the bit offset also means flow type */
> > > --
> > > 1.9.3
> > >
> > >
> > 
> > You'll need to at least move this to the end of the structure to avoid ABI breakage,
> > but even then, since the examples statically allocate this struct on the stack, you
> > need to worry about previously compiled applications not having enough space
> > allocated.  Is there a hole in the struct that this can fit into to avoid changing the
> > other member offsets?
> > Neil
> 
>