[dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director
Wu, Jingjing
jingjing.wu at intel.com
Wed Oct 29 02:29:36 CET 2014
Hi, Thomas
Thanks for your comments.
Jingjing
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, October 28, 2014 9:18 PM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for
> adding/deleting flow director
>
> 2014-10-28 01:18, Wu, Jingjing:
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > > 2014-10-22 09:01, Jingjing Wu:
> > > > +#define RTE_ETH_FDIR_MAX_FLEXWORD_LEN 8
> > > > +/**
> > > > + * A structure used to contain extend input of flow */ struct
> > > > +rte_eth_fdir_flow_ext {
> > > > + uint16_t vlan_tci;
> > > > + uint8_t num_flexwords; /**< number of flexwords */
> > > > + uint16_t flexwords[RTE_ETH_FDIR_MAX_FLEXWORD_LEN];
> > > > + uint16_t dest_id; /**< destination vsi or pool id*/
> > > > +};
> > >
> > > Flexword should be explained.
> > >
> > The flexword means the application can choose a part of packet's
> > payload as key words to compare match. It is flexible.
> > In Ixgbe, the flexwords is 1 word (2 bytes), while Fortville extend it to 8
> words.
>
> OK. The problem is that I don't know how to fill the flexwords bytes.
> You should explain it in the doxygen comment.
> You say it's flexible. Is it usable with a non-IP packet?
> Please explain constraints and syntax.
>
OK. Will add more explanations in comments.
> > > > +struct rte_eth_fdir_input {
> > > > + enum rte_eth_flow_type flow_type; /**< type of flow */
> > > > + union rte_eth_fdir_flow flow; /**< specific flow structure */
> > > > + struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info
> > > > +*/ };
> > >
> > > I don't understand the logic behind flow/flow_ext.
> > > Why flow_ext is not merged into flow ?
> > >
> > The flow defines the key words for each flow_type, while the flow_ext
> > has other elements which have little to do with flow_type.
> > For example the flexword, dst_id (can used as pool id), I think it is
> > not reasonable to make it as an element in the flow.
>
> Sorry, I don't understand.
> flow and flow_ext are associated with a flow type.
Take an example like: flow_type is IPV4, and the key words in IP is supposed
to be dst_ip and src_ip. Other fields like dst_id has little to do with IPV4.
> The comments are "specific flow structure" and "specific flow info" which
> doesn't bring any useful information.
>
OK, I think I need to change the comments.
> > > > +/**
> > > > + * Flow director report status
> > > > + */
> > > > +enum rte_eth_fdir_status {
> > > > + RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< no report FDIR. */
> > > > + RTE_ETH_FDIR_REPORT_FD_ID, /**< only report FD ID. */
> > > > + RTE_ETH_FDIR_REPORT_FD_ID_FLEX_4, /**< report FD ID and 4 flex
> bytes. */
> > > > + RTE_ETH_FDIR_REPORT_FLEX_8, /**< report 8 flex bytes. */
> > > > +};
> > >
> > > The names and explanations are cryptics.
> >
> > The enum defines what will be reported when FIR match.
> > Can be FD_ID or flex bytes
>
> Just to be sure, have you understood that I'm requesting more explanations
> in the comments to allow users of your API to understand it?
>
OK, get it.
> > > > +/**
> > > > + * A structure used to define an action when match FDIR packet filter.
> > > > + */
> > > > +struct rte_eth_fdir_action {
> > > > + uint16_t rx_queue; /**< queue assigned to if fdir match. */
> > > > + uint16_t cnt_idx; /**< statistic counter index */
> > >
> > > what is the action of "statistic counter index"?
> >
> > When FD match happened, the counter will increase.
>
> Which counter?
> Which value should be set in cnt_idx?
>
A hardware counter provided in Fortville. It supposed that the user know about
the hardware, or just set to 0 if don't specify a counter, a default counter will be
used for all entries. I will add more comments.
> > Fortville can support to configure the different counter for filter entries.
> > The action is a part of a filter entry, so this element means which counter
> the entry will use.
>
> I perfectly understand that you are writing some code to allow usage of
> Fortville features through DPDK. Thank you for bringing new features.
> But I want to know if I'm allowed to use it without reading the Fortville
> datasheet?
Yes, you can. But for same extended functions, need more explanation.
You are correct, I need to add more explanation.
> And could this API be shared by other hardwares (e.g. ixgbe)?
Yes, I also considered about it during design. And the integrating ixgbe's flow
director to the API is ready. I plan to send another patch for it when
this patch set is applied.
>
> > > > + uint8_t drop; /**< accept or reject */
> > > > + uint8_t flex_off; /**< offset used define words to report */
> > >
> > > still difficult to understand the flex logic
> >
> > Just as mentioned above, Fortville can support 8 flex words comparing.
> > But for reporting, only 4 or 8 bytes in the flex words can be reported.
> > So need to specify the offset to choose the 4 or 8 bytes.
>
> I don't even know what are the meaning of these 4 or 8 bytes.
Additional, these 4 or 8 bytes are a part of the 8 flex words.
> Please don't consider that every DPDK user know the Fortville datasheet.
OK. More comments.
>
> > > > +/**
> > > > + * A structure used to define the flow director filter entry by
> > > > +filter_ctl API
> > > > + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_ADD and
> > > > + * RTE_ETH_FILTER_DELETE operations.
> > > > + */
> > > > +struct rte_eth_fdir_filter {
> > > > + uint32_t soft_id; /**< id */
> > >
> > > Should the application handle the id numbering?
> > > Why is it soft_id instead of id?
> >
> > Yes, the soft_id is just id, is also reported id when entry match.
> > The id is specified by user, and can be used to identify this entry,
> > application should handle it.
>
> OK, so explain it in comments.
OK.
> Or better, generate and return the id when creating a filter.
>
> Thanks
> --
> Thomas
More information about the dev
mailing list