> On Mar 7, 2017, at 6:56 AM, Thomas Monjalon wrote:
>
> 2017-03-07 10:14, Dumitrescu, Cristian:
>> From: Stephen Hemminger [mailto:step...@networkplumber.org]
>>> On Mon, 6 Mar 2017 20:41:27 +
>>> "Wiles, Keith" wrote:
>>>
Being able to add features without having to change DPDK mayb
2017-03-07 10:14, Dumitrescu, Cristian:
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> > On Mon, 6 Mar 2017 20:41:27 +
> > "Wiles, Keith" wrote:
> >
> > > Being able to add features without having to change DPDK maybe a strong
> > feature for companies that have special needs
@cavium.com; hemant.agra...@nxp.com;
> shreyansh.j...@nxp.com; Richardson, Bruce
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] ethdev: add capability control API
>
> On Mon, 6 Mar 2017 20:41:27 +
> "Wiles, Keith" wrote:
>
> > Being able to add features without having
On Mon, 6 Mar 2017 20:41:27 +
"Wiles, Keith" wrote:
> Being able to add features without having to change DPDK maybe a strong
> feature for companies that have special needs for its application. They just
> need to add a rte_eth_capability enum in a range that they want to control
> (which
> On Mar 6, 2017, at 2:21 PM, Thomas Monjalon wrote:
>
>> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
>>> 2017-03-06 16:35, Dumitrescu, Cristian:
>> +int rte_eth_dev_capability_ops_get(uint8_t port_id,
>> +enum rte_eth_capability cap, void *arg);
>
> What is
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> > 2017-03-06 16:35, Dumitrescu, Cristian:
> > > > > +int rte_eth_dev_capability_ops_get(uint8_t port_id,
> > > > > + enum rte_eth_capability cap, void *arg);
> > > >
> > > > What is the benefit of getting different kind of capabilitie
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monja...@6wind.com]
> Sent: Monday, March 6, 2017 4:57 PM
> To: Dumitrescu, Cristian
> Cc: dev@dpdk.org; jerin.ja...@caviumnetworks.com;
> balasubramanian.manoha...@cavium.com; hemant.agra...@nxp.com;
> shreyansh.j...@nxp.com; W
2017-03-06 16:35, Dumitrescu, Cristian:
> Hi Thomas,
>
> Thanks for reviewing this proposal.
>
>
> > > Signed-off-by: Cristian Dumitrescu
> > > Acked-by: Keith Wiles
> > > Acked-by: Jerin Jacob
> > > Acked-by: Hemant Agrawal
> > [...]
> > > +enum rte_eth_capability {
> > > + RTE_ETH_CAPABILI
>
> It is difficult to follow previous discussions as you do not
> keep threading with --in-reply-to.
>
Apologies, will do in the future.
Hi Thomas,
Thanks for reviewing this proposal.
> > Signed-off-by: Cristian Dumitrescu
> > Acked-by: Keith Wiles
> > Acked-by: Jerin Jacob
> > Acked-by: Hemant Agrawal
> [...]
> > +enum rte_eth_capability {
> > + RTE_ETH_CAPABILITY_FLOW = 0, /**< Flow */
> > + RTE_ETH_CAPABILITY_TM, /**<
Hi Cristian,
2017-03-04 01:10, Cristian Dumitrescu:
> struct rte_flow_ops *eth_flow_ops;
> int rte = rte_eth_dev_filter_ctrl(eth_port_id,
> RTE_ETH_FILTER_GENERIC, RTE_ETH_FILTER_GET, ð_flow_ops);
>
> Unfortunately, the rte_flow opportunistically uses the
> rte_eth_dev_filter_ctrl()
> API
The rte_flow feature breaks the current monolithic approach for ethdev and
introduces the new generic flow API to ethdev using a plugin-like approach.
Basically, the rte_flow API is still logically part of ethdev:
- It extends the ethdev functionality: rte_flow is a new feature/capability
of eth
12 matches
Mail list logo
