[dpdk-dev] [PATCH v2 1/5] net/i40e: support pipeline personalization profile

Xing, Beilei beilei.xing at intel.com
Thu Mar 9 04:30:42 CET 2017


> -----Original Message-----
> From: Yigit, Ferruh
> Sent: Wednesday, March 8, 2017 8:07 PM
> To: Xing, Beilei <beilei.xing at intel.com>; Wu, Jingjing <jingjing.wu at intel.com>
> Cc: Zhang, Helin <helin.zhang at intel.com>; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2 1/5] net/i40e: support pipeline
> personalization profile
> 
> On 3/3/2017 7:39 AM, Beilei Xing wrote:
> > Add admin queue functions for Pipeline Personalization Profile AQ
> > commands defined in DCR 287:
> 
> You can drop DCR reference here.

Sorry as the DCR in my hand is also draft and intel confidential. I will share it if it's released.

> 
> >  - Write Recipe Command buffer (Opcode: 0x0270)
> >  - Get Applied Profiles list (Opcode: 0x0271) This patch will be moved
> > to base driver in future.
> >
> > Signed-off-by: Beilei Xing <beilei.xing at intel.com>
> 
> <...>
> 
> > +
> > +/**
> > + * i40e_aq_write_ppp - Write pipeline personalization profile (ppp)
> > + * @hw: pointer to the hw struct
> > + * @buff: command buffer (size in bytes = buff_size)
> > + * @buff_size: buffer size in bytes
> > + * @track_id: package tracking id
> > + * @error_offset: returns error offset
> > + * @error_info: returns error information
> > + * @cmd_details: pointer to command details structure or NULL  **/
> > +enum i40e_status_code i40e_aq_write_ppp(struct i40e_hw *hw, void
> > +*buff,
> > +				   uint16_t buff_size, uint32_t track_id,
> > +				   uint32_t *error_offset, uint32_t
> *error_info,
> > +				   struct i40e_asq_cmd_details *cmd_details)
> 
> Is there a reason to not make these functions "static" ?

No.  In fact, I design the patch in base driver first, and follow the base code style.
Agree to use "static" if the function is in PMD.

> 
> What do you think making function calls more consistent, below is
> "i40e_aq_get_ppp_list", so thi can be "i40e_aq_ppp_write"
> 
> And since this is NIC driver, ppp cane be confused with "Point-to-Point
> Protocol", is there any possible abbreviation or capitalization to prevent
> confusion?

Yes, will consider about it.

> 
> <...>
> 
> > +/**
> > + * i40e_find_segment_in_package
> > + * @segment_type: the segment type to search for (i.e.,
> > +SEGMENT_TYPE_I40E)
> > + * @pkg_hdr: pointer to the package header to be searched
> > + *
> > + * This function searches a package file for a particular segment
> > +type. On
> > + * success it returns a pointer to the segment header, otherwise it
> > +will
> > + * return NULL.
> > + */
> > +struct i40e_generic_seg_header *
> > +i40e_find_segment_in_package(uint32_t segment_type,
> > +			     struct i40e_package_header *pkg_hdr)
> 
> This function name is also generic, what segment, what package. if this is
> related to the ppp, please use relevant function name.
OK.

> 
> <...>
> 
> > +
> > +/**
> > + * i40e_write_profile
> > + * @hw: pointer to the hardware structure
> > + * @profile: pointer to the profile segment of the package to be
> > +downloaded
> > + * @track_id: package tracking id
> > + *
> > + * Handles the download of a complete package.
> > + */
> > +enum i40e_status_code
> > +i40e_write_profile(struct i40e_hw *hw, struct i40e_profile_segment
> *profile,
> > +		   uint32_t track_id)
> 
> What about having "ppp" in API, like i40e_ppp_write()?

Seems good.


> 
> <...>
> 
> > +struct i40e_profile_section_header {
> > +	uint16_t tbl_size;
> > +	uint16_t data_end;
> > +	struct {
> > +#define SECTION_TYPE_INFO	0x0000010
> > +#define SECTION_TYPE_MMIO	0x0000800
> > +#define SECTION_TYPE_AQ		0x0000801
> 
> unaligned
> 
> > +#define SECTION_TYPE_NOTE	0x80000000
> > +#define SECTION_TYPE_NAME	0x80000001
> > +		uint32_t type;
> > +		uint32_t offset;
> > +		uint32_t size;
> > +	} section;
> > +};
> > +
> 
> <...>
> 
> > @@ -805,6 +915,23 @@ int i40e_dev_tunnel_filter_set(struct i40e_pf *pf,
> >  			       struct rte_eth_tunnel_filter_conf *tunnel_filter,
> >  			       uint8_t add);
> >  int i40e_fdir_flush(struct rte_eth_dev *dev);
> > +enum i40e_status_code i40e_aq_write_ppp(struct i40e_hw *hw, void
> *buff,
> > +				uint16_t buff_size, uint32_t track_id,
> > +				uint32_t *error_offset, uint32_t *error_info,
> > +				struct i40e_asq_cmd_details *cmd_details);
> enum i40e_status_code
> > +i40e_aq_get_ppp_list(struct i40e_hw *hw, void *buff,
> > +				   uint16_t buff_size, uint8_t flags,
> > +				   struct i40e_asq_cmd_details *cmd_details);
> struct
> > +i40e_generic_seg_header * i40e_find_segment_in_package(uint32_t
> > +segment_type,
> > +			     struct i40e_package_header *pkg_header); enum
> > +i40e_status_code i40e_write_profile(struct i40e_hw *hw, struct
> > +i40e_profile_segment *i40e_seg,
> > +		   uint32_t track_id);
> > +enum i40e_status_code
> > +i40e_add_pinfo_to_list(struct i40e_hw *hw,
> > +		       struct i40e_profile_segment *profile,
> > +		       uint8_t *profile_info_sec, uint32_t track_id);
> 
> These declarations can go away if you make functions static.
Yes.

> 
> >
> >  #define I40E_DEV_TO_PCI(eth_dev) \
> >  	RTE_DEV_TO_PCI((eth_dev)->device)
> >



More information about the dev mailing list