All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerin Jacob <jerin.jacob@caviumnetworks.com>
To: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
Cc: dev@dpdk.org, thomas.monjalon@6wind.com, hemant.agrawal@nxp.com
Subject: Re: [PATCH 1/2] ethdev: add capability control API
Date: Tue, 21 Feb 2017 18:15:42 +0530	[thread overview]
Message-ID: <20170221124541.GA4411@localhost.localdomain> (raw)
In-Reply-To: <1486735550-149878-2-git-send-email-cristian.dumitrescu@intel.com>

On Fri, Feb 10, 2017 at 02:05:49PM +0000, Cristian Dumitrescu wrote:
> 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 ethdev;
> - all its functions work on an Ethernet device: the first parameter of the
>   rte_flow functions is Ethernet device port ID.
> 
> At the same time, the rte_flow API is a sort of capability plugin for ethdev:
> - the rte_flow API functions have their own name space: they are called
>   rte_flow_operationXYZ() as opposed to rte_eth_dev_flow_operationXYZ());
> - the rte_flow API functions are placed in separate files in the same
>   librte_ether folder as opposed to rte_ethdev.[hc].
> 
> The way it works is by using the existing ethdev API function
> rte_eth_dev_filter_ctrl() to query the current Ethernet device port ID for the
> support of the rte_flow capability and return the pointer to the
> rte_flow operations when supported and NULL otherwise:
> 
> 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, &eth_flow_ops);
> 
> Unfortunately, the rte_flow opportunistically uses the rte_eth_dev_filter_ctrl()
> API function, which is applicable just to RX-side filters as opposed to
> introducing a mechanism that could be used by any capability in a generic way.
> 
> This is the gap that addressed by the current patch. This mechanism is intended
> to be used to introduce new capabilities into ethdev in a modular plugin-like
> approach, such as hierarchical scheduler. Over time, if agreed, it can also be
> used for exposing the existing Ethernet device capabilities in a modular way,
> such as: xstats, filters, multicast, mirroring, tunnels, time stamping, eeprom,
> bypass, etc.
> 
> Signed-off-by: Cristian Dumitrescu <cristian.dumitrescu@intel.com>
> ---
>  lib/librte_ether/rte_ethdev.c          | 13 +++++++++++++
>  lib/librte_ether/rte_ethdev.h          | 29 +++++++++++++++++++++++++++++
>  lib/librte_ether/rte_ether_version.map |  7 +++++++
>  3 files changed, 49 insertions(+)
> 
> diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
> index eb0a94a..ae187c4 100644
> --- a/lib/librte_ether/rte_ethdev.c
> +++ b/lib/librte_ether/rte_ethdev.c
> @@ -2802,6 +2802,19 @@ rte_eth_dev_filter_ctrl(uint8_t port_id, enum rte_filter_type filter_type,
>  	return (*dev->dev_ops->filter_ctrl)(dev, filter_type, filter_op, arg);
>  }
>  
> +int
> +rte_eth_dev_capability_control(uint8_t port_id, enum rte_eth_capability cap,
> +	void *arg)
> +{
> +	struct rte_eth_dev *dev;
> +
> +	RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
> +
> +	dev = &rte_eth_devices[port_id];
> +	RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->cap_ctrl, -ENOTSUP);
> +	return (*dev->dev_ops->cap_ctrl)(dev, cap, arg);
> +}
> +
>  void *
>  rte_eth_add_rx_callback(uint8_t port_id, uint16_t queue_id,
>  		rte_rx_callback_fn fn, void *user_param)
> diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
> index c17bbda..43ffb9e 100644
> --- a/lib/librte_ether/rte_ethdev.h
> +++ b/lib/librte_ether/rte_ethdev.h
> @@ -1073,6 +1073,12 @@ TAILQ_HEAD(rte_eth_dev_cb_list, rte_eth_dev_callback);
>   * structure associated with an Ethernet device.
>   */
>  
> +enum rte_eth_capability {
> +	RTE_ETH_CAPABILITY_FLOW = 0, /**< Flow */
> +	RTE_ETH_CAPABILITY_SCHED, /**< Hierarchical Scheduler */
> +	RTE_ETH_CAPABILITY_MAX
> +};
> +
>  typedef int  (*eth_dev_configure_t)(struct rte_eth_dev *dev);
>  /**< @internal Ethernet device configuration. */
>  
> @@ -1427,6 +1433,10 @@ typedef int (*eth_filter_ctrl_t)(struct rte_eth_dev *dev,
>  				 void *arg);
>  /**< @internal Take operations to assigned filter type on an Ethernet device */
>  
> +typedef int (*eth_capability_control_t)(struct rte_eth_dev *dev,
> +	enum rte_eth_capability cap, void *arg);
> +/**< @internal Take capability operations on an Ethernet device */
> +
>  typedef int (*eth_get_dcb_info)(struct rte_eth_dev *dev,
>  				 struct rte_eth_dcb_info *dcb_info);
>  /**< @internal Get dcb information on an Ethernet device */
> @@ -1548,6 +1558,8 @@ struct eth_dev_ops {
>  	eth_timesync_adjust_time   timesync_adjust_time; /** Adjust the device clock. */
>  	eth_timesync_read_time     timesync_read_time; /** Get the device clock time. */
>  	eth_timesync_write_time    timesync_write_time; /** Set the device clock time. */
> +
> +	eth_capability_control_t   cap_ctrl; /**< capability control. */
>  };
>  
>  /**
> @@ -3890,6 +3902,23 @@ int rte_eth_dev_filter_ctrl(uint8_t port_id, enum rte_filter_type filter_type,
>  			enum rte_filter_op filter_op, void *arg);
>  
>  /**
> + * Take capability operations on an Ethernet device.
> + *
> + * @param port_id
> + *   The port identifier of the Ethernet device.
> + * @param cap
> + *   The capability of the Ethernet device
> + * @param arg
> + *   A pointer to arguments defined specifically for the operation.

Better to add _out_ for output  parameter.
@param[out] arg.

> + * @return
> + *   - (0) if successful.
> + *   - (-ENOTSUP) if hardware doesn't support.
> + *   - (-ENODEV) if *port_id* invalid.
> + */
> +int rte_eth_dev_capability_control(uint8_t port_id,
> +	enum rte_eth_capability cap, void *arg);


I like the idea of "plugin" interface to ethdev to accommodate
hierarchical scheduler ops with different name space like rte_flow.
Though I don't have strong opinion on the API
name, I think its better to have something end with _ops_get instead of
capability_control

With that suggestion,

Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>

> +
> +/**
>   * Get DCB information on an Ethernet device.
>   *
>   * @param port_id
> diff --git a/lib/librte_ether/rte_ether_version.map b/lib/librte_ether/rte_ether_version.map
> index c6c9d0d..d00cb5c 100644
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -154,3 +154,10 @@ DPDK_17.02 {
>  	rte_flow_validate;
>  
>  } DPDK_16.11;
> +
> +DPDK_17.05 {
> +	global:
> +
> +	rte_eth_dev_capability_control;
> +
> +} DPDK_17.02;
> -- 
> 2.5.0
> 

  parent reply	other threads:[~2017-02-21 12:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10 14:05 [PATCH 0/2] ethdev: abstraction layer for QoS hierarchical scheduler Cristian Dumitrescu
2017-02-10 14:05 ` [PATCH 1/2] ethdev: add capability control API Cristian Dumitrescu
2017-02-10 20:29   ` Wiles, Keith
2017-02-11  6:38   ` Jerin Jacob
2017-02-11 13:07     ` Wiles, Keith
2017-02-13 11:32       ` Dumitrescu, Cristian
2017-02-21 12:45   ` Jerin Jacob [this message]
2017-02-22 10:56     ` Hemant Agrawal
2017-02-10 14:05 ` [PATCH 2/2] ethdev: add hierarchical scheduler API Cristian Dumitrescu
2017-02-21 10:35   ` Hemant Agrawal
2017-02-21 13:44     ` Dumitrescu, Cristian
2017-03-02 11:47   ` Jerin Jacob

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170221124541.GA4411@localhost.localdomain \
    --to=jerin.jacob@caviumnetworks.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=hemant.agrawal@nxp.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.