[dpdk-dev,v15,1/4] ethdev: add apis to support access device info
Commit Message
add new apis:
- rte_eth_dev_default_mac_addr_set
- rte_eth_dev_get_reg_length
- rte_eth_dev_get_reg_info
- rte_eth_dev_get_eeprom_length
- rte_eth_dev_get_eeprom
- rte_eth_dev_set_eeprom
to enable reading device parameters (mac-addr, register,
eeprom) based upon ethtool alike
data parameter specification.
Signed-off-by: Liang-Min Larry Wang <liang-min.wang@intel.com>
---
lib/librte_ether/Makefile | 1 +
lib/librte_ether/rte_eth_dev_info.h | 57 ++++++++++++++++
lib/librte_ether/rte_ethdev.c | 83 ++++++++++++++++++++++-
lib/librte_ether/rte_ethdev.h | 118 +++++++++++++++++++++++++++++++++
lib/librte_ether/rte_ether_version.map | 6 ++
5 files changed, 264 insertions(+), 1 deletion(-)
create mode 100644 lib/librte_ether/rte_eth_dev_info.h
Comments
2015-07-13 22:18, Liang-Min Larry Wang:
> --- a/lib/librte_ether/Makefile
> +++ b/lib/librte_ether/Makefile
> @@ -51,6 +51,7 @@ SRCS-y += rte_ethdev.c
> SYMLINK-y-include += rte_ether.h
> SYMLINK-y-include += rte_ethdev.h
> SYMLINK-y-include += rte_eth_ctrl.h
> +SYMLINK-y-include += rte_eth_dev_info.h
This file is not related to ethernet so it could be named rte_dev_info.h
> +struct rte_dev_reg_info {
> + void *buf; /**< Buffer for register */
Maybe data would be more accurate.
> + uint32_t offset; /**< Offset for 1st register to fetch */
Please precise offset from which point?
Why offset is needed?
> + uint32_t leng; /**< Number of registers to fetch */
2 more characters for free: length
> +struct rte_dev_eeprom_info {
> + void *buf; /**< Buffer for eeprom */
> + uint32_t offset; /**< Offset for 1st eeprom location to access */
> + uint32_t leng; /**< Length of eeprom region to access */
Same as above for these 3 fields.
> + uint32_t magic; /**< Device ID */
What means magic? Is it always a device id?
> --- a/lib/librte_ether/rte_ether_version.map
> +++ b/lib/librte_ether/rte_ether_version.map
> @@ -114,5 +114,11 @@ DPDK_2.1 {
> rte_eth_timesync_enable;
> rte_eth_timesync_read_rx_timestamp;
> rte_eth_timesync_read_tx_timestamp;
> + rte_eth_dev_default_mac_addr_set;
> + rte_eth_dev_reg_length;
> + rte_eth_dev_reg_info;
> + rte_eth_dev_eeprom_length;
> + rte_eth_dev_get_eeprom;
> + rte_eth_dev_set_eeprom;
It is not in alphabetical order.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, July 15, 2015 2:16 AM
> To: Wang, Liang-min
> Cc: dev@dpdk.org; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 1/4] ethdev: add apis to support access
> device info
>
> 2015-07-13 22:18, Liang-Min Larry Wang:
> > --- a/lib/librte_ether/Makefile
> > +++ b/lib/librte_ether/Makefile
> > @@ -51,6 +51,7 @@ SRCS-y += rte_ethdev.c
> > SYMLINK-y-include += rte_ether.h
> > SYMLINK-y-include += rte_ethdev.h
> > SYMLINK-y-include += rte_eth_ctrl.h
> > +SYMLINK-y-include += rte_eth_dev_info.h
>
> This file is not related to ethernet so it could be named rte_dev_info.h
>
>
> > +struct rte_dev_reg_info {
> > + void *buf; /**< Buffer for register */
>
> Maybe data would be more accurate.
>
> > + uint32_t offset; /**< Offset for 1st register to fetch */
>
> Please precise offset from which point?
> Why offset is needed?
>
Is C always 0-base?
The offset is introduced because one of the review requesting to support partial register read,
meaning reading single register or a set of registers.
As comment in my reply, this implementation only supports total register dump,
but the data structure design allows future expansion to support this request.
> > + uint32_t leng; /**< Number of registers to fetch */
>
> 2 more characters for free: length
>
>
> > +struct rte_dev_eeprom_info {
> > + void *buf; /**< Buffer for eeprom */
> > + uint32_t offset; /**< Offset for 1st eeprom location to access */
> > + uint32_t leng; /**< Length of eeprom region to access */
>
> Same as above for these 3 fields.
>
> > + uint32_t magic; /**< Device ID */
>
> What means magic? Is it always a device id?
This field is the same as defined in kernel ethtool data structure.
>
>
> > --- a/lib/librte_ether/rte_ether_version.map
> > +++ b/lib/librte_ether/rte_ether_version.map
> > @@ -114,5 +114,11 @@ DPDK_2.1 {
> > rte_eth_timesync_enable;
> > rte_eth_timesync_read_rx_timestamp;
> > rte_eth_timesync_read_tx_timestamp;
> > + rte_eth_dev_default_mac_addr_set;
> > + rte_eth_dev_reg_length;
> > + rte_eth_dev_reg_info;
> > + rte_eth_dev_eeprom_length;
> > + rte_eth_dev_get_eeprom;
> > + rte_eth_dev_set_eeprom;
>
> It is not in alphabetical order.
Is there a document on such requirement?
I'm asking this question because different API's are added at different time.
Does this comment apply on relative order or absolute order meaning order relative to mainline code?
2015-07-15 10:07, Wang, Liang-min:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Please precise offset from which point?
> > Why offset is needed?
> >
> Is C always 0-base?
> The offset is introduced because one of the review requesting to support partial register read,
> meaning reading single register or a set of registers.
> As comment in my reply, this implementation only supports total register dump,
> but the data structure design allows future expansion to support this request.
OK, so the comment should be something like "Offset in register table"
> > What means magic? Is it always a device id?
> This field is the same as defined in kernel ethtool data structure.
Not an excellent argument :)
Actually you didn't answer.
> > > --- a/lib/librte_ether/rte_ether_version.map
> > > +++ b/lib/librte_ether/rte_ether_version.map
> > > @@ -114,5 +114,11 @@ DPDK_2.1 {
> > > rte_eth_timesync_enable;
> > > rte_eth_timesync_read_rx_timestamp;
> > > rte_eth_timesync_read_tx_timestamp;
> > > + rte_eth_dev_default_mac_addr_set;
> > > + rte_eth_dev_reg_length;
> > > + rte_eth_dev_reg_info;
> > > + rte_eth_dev_eeprom_length;
> > > + rte_eth_dev_get_eeprom;
> > > + rte_eth_dev_set_eeprom;
> >
> > It is not in alphabetical order.
> Is there a document on such requirement?
No, only emails.
Every .map are alphabetically sorted. It's easier to check symbols.
> I'm asking this question because different API's are added at different time.
> Does this comment apply on relative order or absolute order meaning order relative to mainline code?
Relative to mainline. Conflicts are handled when applying.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, July 15, 2015 6:27 AM
> To: Wang, Liang-min
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 1/4] ethdev: add apis to support access
> device info
>
> 2015-07-15 10:07, Wang, Liang-min:
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > > Please precise offset from which point?
> > > Why offset is needed?
> > >
> > Is C always 0-base?
> > The offset is introduced because one of the review requesting to support
> partial register read,
> > meaning reading single register or a set of registers.
> > As comment in my reply, this implementation only supports total register
> dump,
> > but the data structure design allows future expansion to support this
> request.
>
> OK, so the comment should be something like "Offset in register table"
>
> > > What means magic? Is it always a device id?
> > This field is the same as defined in kernel ethtool data structure.
>
> Not an excellent argument :)
> Actually you didn't answer.
>
I could not speak for other devices. For igb and ixgbe, it's device id.
Based upon literature search, this field is used by device driver to provide extra information.
What would be your suggestion?
> > > > --- a/lib/librte_ether/rte_ether_version.map
> > > > +++ b/lib/librte_ether/rte_ether_version.map
> > > > @@ -114,5 +114,11 @@ DPDK_2.1 {
> > > > rte_eth_timesync_enable;
> > > > rte_eth_timesync_read_rx_timestamp;
> > > > rte_eth_timesync_read_tx_timestamp;
> > > > + rte_eth_dev_default_mac_addr_set;
> > > > + rte_eth_dev_reg_length;
> > > > + rte_eth_dev_reg_info;
> > > > + rte_eth_dev_eeprom_length;
> > > > + rte_eth_dev_get_eeprom;
> > > > + rte_eth_dev_set_eeprom;
> > >
> > > It is not in alphabetical order.
> > Is there a document on such requirement?
>
> No, only emails.
> Every .map are alphabetically sorted. It's easier to check symbols.
>
> > I'm asking this question because different API's are added at different
> time.
> > Does this comment apply on relative order or absolute order meaning
> order relative to mainline code?
>
> Relative to mainline. Conflicts are handled when applying.
2015-07-15 10:48, Wang, Liang-min:
> > > > What means magic? Is it always a device id?
> > > This field is the same as defined in kernel ethtool data structure.
> >
> > Not an excellent argument :)
> > Actually you didn't answer.
> >
> I could not speak for other devices. For igb and ixgbe, it's device id.
> Based upon literature search, this field is used by device driver to provide extra information.
> What would be your suggestion?
I don't have any suggestion.
You are defining a new API in DPDK, so our concern must be to check
that it will be easily understood by users and PMD developers.
If you don't really know what this field will be for, others won't know.
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Wednesday, July 15, 2015 7:21 AM
> To: Wang, Liang-min
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v15 1/4] ethdev: add apis to support access
> device info
>
> 2015-07-15 10:48, Wang, Liang-min:
> > > > > What means magic? Is it always a device id?
> > > > This field is the same as defined in kernel ethtool data structure.
> > >
> > > Not an excellent argument :)
> > > Actually you didn't answer.
> > >
> > I could not speak for other devices. For igb and ixgbe, it's device id.
> > Based upon literature search, this field is used by device driver to provide
> extra information.
> > What would be your suggestion?
>
> I don't have any suggestion.
> You are defining a new API in DPDK, so our concern must be to check
> that it will be easily understood by users and PMD developers.
> If you don't really know what this field will be for, others won't know.
No, I meant it's device driver dependent.
If I keep the same naming convention following kernel ethtool defined,
and adding comment like "device-specific magic key, such as device-id".
Would that be acceptable from you?
This data structure is defined to be compatible with kernel ethtool API,
and magic key is device specific and known to ethtool API users.
2015-07-15 11:36, Wang, Liang-min:
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > 2015-07-15 10:48, Wang, Liang-min:
> > > > > > What means magic? Is it always a device id?
> > > > > This field is the same as defined in kernel ethtool data structure.
> > > >
> > > > Not an excellent argument :)
> > > > Actually you didn't answer.
> > > >
> > > I could not speak for other devices. For igb and ixgbe, it's device id.
> > > Based upon literature search, this field is used by device driver to provide
> > extra information.
> > > What would be your suggestion?
> >
> > I don't have any suggestion.
> > You are defining a new API in DPDK, so our concern must be to check
> > that it will be easily understood by users and PMD developers.
> > If you don't really know what this field will be for, others won't know.
> No, I meant it's device driver dependent.
> If I keep the same naming convention following kernel ethtool defined,
> and adding comment like "device-specific magic key, such as device-id".
> Would that be acceptable from you?
OK
> This data structure is defined to be compatible with kernel ethtool API,
> and magic key is device specific and known to ethtool API users.
@@ -51,6 +51,7 @@ SRCS-y += rte_ethdev.c
SYMLINK-y-include += rte_ether.h
SYMLINK-y-include += rte_ethdev.h
SYMLINK-y-include += rte_eth_ctrl.h
+SYMLINK-y-include += rte_eth_dev_info.h
# this lib depends upon:
DEPDIRS-y += lib/librte_eal lib/librte_mempool lib/librte_ring lib/librte_mbuf
new file mode 100644
@@ -0,0 +1,57 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2015 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_ETH_DEV_INFO_H_
+#define _RTE_ETH_DEV_INFO_H_
+
+/*
+ * Placeholder for accessing device registers
+ */
+struct rte_dev_reg_info {
+ void *buf; /**< Buffer for register */
+ uint32_t offset; /**< Offset for 1st register to fetch */
+ uint32_t leng; /**< Number of registers to fetch */
+ uint32_t version; /**< Device version */
+};
+
+/*
+ * Placeholder for accessing device eeprom
+ */
+struct rte_dev_eeprom_info {
+ void *buf; /**< Buffer for eeprom */
+ uint32_t offset; /**< Offset for 1st eeprom location to access */
+ uint32_t leng; /**< Length of eeprom region to access */
+ uint32_t magic; /**< Device ID */
+};
+
+#endif /* _RTE_ETH_DEV_INFO_H_ */
@@ -111,7 +111,7 @@
#define VALID_PORTID_OR_ERR_RET(port_id, retval) do { \
if (!rte_eth_dev_is_valid_port(port_id)) { \
PMD_DEBUG_TRACE("Invalid port_id=%d\n", port_id); \
- return -EINVAL; \
+ return retval; \
} \
} while (0)
@@ -2542,6 +2542,27 @@ rte_eth_dev_mac_addr_remove(uint8_t port_id, struct ether_addr *addr)
}
int
+rte_eth_dev_default_mac_addr_set(uint8_t port_id, struct ether_addr *addr)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ if (!is_valid_assigned_ether_addr(addr))
+ return -EINVAL;
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->mac_addr_set, -ENOTSUP);
+
+ /* Update default address in NIC data structure */
+ ether_addr_copy(addr, &dev->data->mac_addrs[0]);
+
+ (*dev->dev_ops->mac_addr_set)(dev, addr);
+
+ return 0;
+}
+
+int
rte_eth_dev_set_vf_rxmode(uint8_t port_id, uint16_t vf,
uint16_t rx_mode, uint8_t on)
{
@@ -3377,3 +3398,63 @@ rte_eth_timesync_read_tx_timestamp(uint8_t port_id, struct timespec *timestamp)
FUNC_PTR_OR_ERR_RET(*dev->dev_ops->timesync_read_tx_timestamp, -ENOTSUP);
return (*dev->dev_ops->timesync_read_tx_timestamp)(dev, timestamp);
}
+
+int
+rte_eth_dev_get_reg_length(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg_length, -ENOTSUP);
+ return (*dev->dev_ops->get_reg_length)(dev);
+}
+
+int
+rte_eth_dev_get_reg_info(uint8_t port_id, struct rte_dev_reg_info *info)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_reg, -ENOTSUP);
+ return (*dev->dev_ops->get_reg)(dev, info);
+}
+
+int
+rte_eth_dev_get_eeprom_length(uint8_t port_id)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_eeprom_length, -ENOTSUP);
+ return (*dev->dev_ops->get_eeprom_length)(dev);
+}
+
+int
+rte_eth_dev_get_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->get_eeprom, -ENOTSUP);
+ return (*dev->dev_ops->get_eeprom)(dev, info);
+}
+
+int
+rte_eth_dev_set_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info)
+{
+ struct rte_eth_dev *dev;
+
+ VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+
+ dev = &rte_eth_devices[port_id];
+ FUNC_PTR_OR_ERR_RET(*dev->dev_ops->set_eeprom, -ENOTSUP);
+ return (*dev->dev_ops->set_eeprom)(dev, info);
+}
@@ -182,6 +182,7 @@ extern "C" {
#include <rte_devargs.h>
#include "rte_ether.h"
#include "rte_eth_ctrl.h"
+#include "rte_eth_dev_info.h"
struct rte_mbuf;
@@ -1255,6 +1256,24 @@ typedef int (*eth_timesync_read_tx_timestamp_t)(struct rte_eth_dev *dev,
struct timespec *timestamp);
/**< @internal Function used to read a TX IEEE1588/802.1AS timestamp. */
+typedef int (*eth_get_reg_length_t)(struct rte_eth_dev *dev);
+/**< @internal Retrieve device register count */
+
+typedef int (*eth_get_reg_t)(struct rte_eth_dev *dev,
+ struct rte_dev_reg_info *info);
+/**< @internal Retrieve registers */
+
+typedef int (*eth_get_eeprom_length_t)(struct rte_eth_dev *dev);
+/**< @internal Retrieve eeprom size */
+
+typedef int (*eth_get_eeprom_t)(struct rte_eth_dev *dev,
+ struct rte_dev_eeprom_info *info);
+/**< @internal Retrieve eeprom data */
+
+typedef int (*eth_set_eeprom_t)(struct rte_eth_dev *dev,
+ struct rte_dev_eeprom_info *info);
+/**< @internal Program eeprom data */
+
#ifdef RTE_NIC_BYPASS
enum {
@@ -1394,6 +1413,17 @@ struct eth_dev_ops {
reta_update_t reta_update;
/** Query redirection table. */
reta_query_t reta_query;
+
+ eth_get_reg_length_t get_reg_length;
+ /**< Get # of registers */
+ eth_get_reg_t get_reg;
+ /**< Get registers */
+ eth_get_eeprom_length_t get_eeprom_length;
+ /**< Get eeprom length */
+ eth_get_eeprom_t get_eeprom;
+ /**< Get eeprom data */
+ eth_set_eeprom_t set_eeprom;
+ /**< Set eeprom */
/* bypass control */
#ifdef RTE_NIC_BYPASS
bypass_init_t bypass_init;
@@ -3021,6 +3051,21 @@ int rte_eth_dev_mac_addr_add(uint8_t port, struct ether_addr *mac_addr,
int rte_eth_dev_mac_addr_remove(uint8_t port, struct ether_addr *mac_addr);
/**
+ * Set the default MAC address.
+ *
+ * @param port
+ * The port identifier of the Ethernet device.
+ * @param mac_addr
+ * New default MAC address.
+ * @return
+ * - (0) if successful, or *mac_addr* didn't exist.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * M
+ * - (-ENODEV) if *port* invalid.
+ */
+int rte_eth_dev_default_mac_addr_set(uint8_t port, struct ether_addr *mac_addr);
+
+/**
* Update Redirection Table(RETA) of Receive Side Scaling of Ethernet device.
*
* @param port
@@ -3654,6 +3699,79 @@ int rte_eth_remove_rx_callback(uint8_t port_id, uint16_t queue_id,
int rte_eth_remove_tx_callback(uint8_t port_id, uint16_t queue_id,
struct rte_eth_rxtx_callback *user_cb);
+/**
+ * Retrieve number of available registers for access
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @return
+ * - (>=0) number of registers if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ * - others depends on the specific operations implementation.
+ */
+int rte_eth_dev_get_reg_length(uint8_t port_id);
+
+/**
+ * Retrieve device registers and register attributes
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param info
+ * The template includes buffer for register data and attribute to be filled.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ * - others depends on the specific operations implementation.
+ */
+int rte_eth_dev_get_reg_info(uint8_t port_id, struct rte_dev_reg_info *info);
+
+/**
+ * Retrieve size of device EEPROM
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @return
+ * - (>=0) EEPROM size if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ * - others depends on the specific operations implementation.
+ */
+int rte_eth_dev_get_eeprom_length(uint8_t port_id);
+
+/**
+ * Retrieve EEPROM and EEPROM attribute
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param info
+ * The template includes buffer for return EEPROM data and
+ * EEPROM attributes to be filled.
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ * - others depends on the specific operations implementation.
+ */
+int rte_eth_dev_get_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info);
+
+/**
+ * Program EEPROM with provided data
+ *
+ * @param port_id
+ * The port identifier of the Ethernet device.
+ * @param info
+ * The template includes EEPROM data for programming and
+ * EEPROM attributes to be filled
+ * @return
+ * - (0) if successful.
+ * - (-ENOTSUP) if hardware doesn't support.
+ * - (-ENODEV) if *port_id* invalid.
+ * - others depends on the specific operations implementation.
+ */
+int rte_eth_dev_set_eeprom(uint8_t port_id, struct rte_dev_eeprom_info *info);
+
#ifdef __cplusplus
}
#endif
@@ -114,5 +114,11 @@ DPDK_2.1 {
rte_eth_timesync_enable;
rte_eth_timesync_read_rx_timestamp;
rte_eth_timesync_read_tx_timestamp;
+ rte_eth_dev_default_mac_addr_set;
+ rte_eth_dev_reg_length;
+ rte_eth_dev_reg_info;
+ rte_eth_dev_eeprom_length;
+ rte_eth_dev_get_eeprom;
+ rte_eth_dev_set_eeprom;
} DPDK_2.0;