Re: [dpdk-dev] [PATCH] doc: add deprecation notice for sched changes
On 24/04/2019 13:37, Jasvinder Singh wrote: Add deprecation note for making changes in data structures, APIs and macros in order to have more traffic classes, flexible mapping of pipe queues to traffic classes, subport level configuration of pipes and queues, etc. These changes are aligned to improvements suggested in the RFC- https://mails.dpdk.org/archives/dev/2018-November/120035.html Signed-off-by: Jasvinder Singh Acked-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index b47c8c254..051ab5c2a 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -79,6 +79,12 @@ Deprecation Notices The field would be added in v19.08. +* sched: To allow more traffic classes, flexible mapping of pipe queues to + traffic classes, and subport level configuration of pipes and queues + changes will be made to macros, data structures and API functions defined + in "rte_sched.h". These changes are aligned to improvements suggested in the + RFC https://mails.dpdk.org/archives/dev/2018-November/120035.html. + * cryptodev: the ``uint8_t *data`` member of ``key`` structure in the xforms structure (``rte_crypto_cipher_xform``, ``rte_crypto_auth_xform``, and ``rte_crypto_aead_xform``) will be changed to ``const uint8_t *data``. Acked-by: Mohammad Abdul Awal
[dpdk-dev] [PATCH v3] vhost: fix null pointer checking
Null value for parameters will cause segfault.
Fixes: d7280c9fff ("vhost: support selective datapath")
Fixes: 72e8543093 ("vhost: add API to get MTU value")
Fixes: a277c71598 ("vhost: refactor code structure")
Fixes: ca33faf9ef ("vhost: introduce API to fetch negotiated features")
Fixes: eb32247457 ("vhost: export guest memory regions")
Fixes: 40ef286f23 ("vhost: export vhost vring info")
Fixes: bd2e0c3fe5 ("vhost: add APIs for live migration")
Fixes: 0b8572a0c1 ("vhost: add external message handling to the API")
Fixes: b4953225ce ("vhost: add APIs for datapath configuration")
Fixes: 5fbb3941da ("vhost: introduce driver features related APIs")
Fixes: 292959c719 ("vhost: cleanup unix socket")
Cc: sta...@dpdk.org
Signed-off-by: Mohammad Abdul Awal
---
v3: fixed per review comments
v2: fixed per review comments
lib/librte_vhost/socket.c | 8 +++-
lib/librte_vhost/vdpa.c | 5 -
lib/librte_vhost/vhost.c | 16
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
index 3da9de62c..1b3a40905 100644
--- a/lib/librte_vhost/socket.c
+++ b/lib/librte_vhost/socket.c
@@ -547,6 +547,9 @@ find_vhost_user_socket(const char *path)
{
int i;
+ if (path == NULL)
+ return NULL;
+
for (i = 0; i < vhost_user.vsocket_cnt; i++) {
struct vhost_user_socket *vsocket = vhost_user.vsockets[i];
@@ -562,7 +565,7 @@ rte_vhost_driver_attach_vdpa_device(const char *path, int
did)
{
struct vhost_user_socket *vsocket;
- if (rte_vdpa_get_device(did) == NULL)
+ if (rte_vdpa_get_device(did) == NULL || path == NULL)
return -1;
pthread_mutex_lock(&vhost_user.mutex);
@@ -975,6 +978,9 @@ rte_vhost_driver_unregister(const char *path)
int count;
struct vhost_user_connection *conn, *next;
+ if (path == NULL)
+ return -1;
+
again:
pthread_mutex_lock(&vhost_user.mutex);
diff --git a/lib/librte_vhost/vdpa.c b/lib/librte_vhost/vdpa.c
index 321e11f17..e91548843 100644
--- a/lib/librte_vhost/vdpa.c
+++ b/lib/librte_vhost/vdpa.c
@@ -49,7 +49,7 @@ rte_vdpa_register_device(struct rte_vdpa_dev_addr *addr,
char device_name[MAX_VDPA_NAME_LEN];
int i;
- if (vdpa_device_num >= MAX_VHOST_DEVICE)
+ if (vdpa_device_num >= MAX_VHOST_DEVICE || addr == NULL || ops == NULL)
return -1;
for (i = 0; i < MAX_VHOST_DEVICE; i++) {
@@ -99,6 +99,9 @@ rte_vdpa_find_device_id(struct rte_vdpa_dev_addr *addr)
struct rte_vdpa_device *dev;
int i;
+ if (addr == NULL)
+ return -1;
+
for (i = 0; i < MAX_VHOST_DEVICE; ++i) {
dev = vdpa_devices[i];
if (dev && is_same_vdpa_device(&dev->addr, addr))
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index e480aeac9..163f4595e 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -447,7 +447,7 @@ rte_vhost_get_mtu(int vid, uint16_t *mtu)
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || mtu == NULL)
return -ENODEV;
if (!(dev->flags & VIRTIO_DEV_READY))
@@ -515,7 +515,7 @@ rte_vhost_get_ifname(int vid, char *buf, size_t len)
{
struct virtio_net *dev = get_device(vid);
- if (dev == NULL)
+ if (dev == NULL || buf == NULL)
return -1;
len = RTE_MIN(len, sizeof(dev->ifname));
@@ -532,7 +532,7 @@ rte_vhost_get_negotiated_features(int vid, uint64_t
*features)
struct virtio_net *dev;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || features == NULL)
return -1;
*features = dev->features;
@@ -547,7 +547,7 @@ rte_vhost_get_mem_table(int vid, struct rte_vhost_memory
**mem)
size_t size;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || mem == NULL)
return -1;
size = dev->mem->nregions * sizeof(struct rte_vhost_mem_region);
@@ -570,7 +570,7 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
struct vhost_virtqueue *vq;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || vring == NULL)
return -1;
if (vring_idx >= VHOST_MAX_VRING)
@@ -763,7 +763,7 @@ int rte_vhost_get_log_base(int vid, uint64_t *log_base,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || log_base == NULL || log_size == NULL)
return -1;
*log_base = dev->log_base;
@@ -777,7 +777,7 @@ int rte_vhost_get_vring_base(int vid, uint16_t queue_id,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ i
Re: [dpdk-dev] [PATCH 2/3] net/virtio: fix null pointer checking
On 04/04/2019 07:22, Tiwei Bie wrote:
On Wed, Apr 03, 2019 at 05:08:11PM +0100, Mohammad Abdul Awal wrote:
Null value of device name should return error without further processing.
Fixes: 1c8489da56 ("net/virtio-user: fix multi-process support")
Signed-off-by: Mohammad Abdul Awal
---
drivers/net/virtio/virtio_user_ethdev.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 129c2b9ef..cefc6da66 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -516,6 +516,10 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
const char *name = rte_vdev_device_name(dev);
+ if (name == NULL) {
+ RTE_LOG(ERR, PMD, "Device name is NULL\n");
+ return -1;
+ }
It seems there is a lot of code in DPDK doesn't do the null
pointer check in this case. Is it worth fixing them as well?
Or should vdev bus guarantee that it won't ask driver to probe
a device without device name (without a device name, vdev bus
shouldn't be able to find a driver to probe actually)?
Thanks,
Tiwei
In fact, the dev->name is already checked for NULL in find_vdev()
function of duing the vdev bus scanning time.
Hence, self-NACK for the patch.
eth_dev = rte_eth_dev_attach_secondary(name);
if (!eth_dev) {
RTE_LOG(ERR, PMD, "Failed to probe %s\n", name);
--
2.17.1
[dpdk-dev] [PATCH v2] vhost: fix null pointer checking
Null value for parameters will cause segfault.
Fixes: d7280c9fff ("vhost: support selective datapath")
Fixes: 72e8543093df ("vhost: add API to get MTU value")
Fixes: a277c71598 ("vhost: refactor code structure")
Fixes: ca33faf9ef ("vhost: introduce API to fetch negotiated features")
Fixes: eb32247457 ("vhost: export guest memory regions")
Fixes: 40ef286f23 ("vhost: export vhost vring info")
Fixes: bd2e0c3fe5 ("vhost: add APIs for live migration")
Fixes: 0b8572a0c1 ("vhost: add external message handling to the API")
Fixes: b4953225ce ("vhost: add APIs for datapath configuration")
Cc: sta...@dpdk.org
Signed-off-by: Mohammad Abdul Awal
---
lib/librte_vhost/socket.c | 2 +-
lib/librte_vhost/vdpa.c | 5 -
lib/librte_vhost/vhost.c | 16
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/lib/librte_vhost/socket.c b/lib/librte_vhost/socket.c
index 3da9de62c..a89665946 100644
--- a/lib/librte_vhost/socket.c
+++ b/lib/librte_vhost/socket.c
@@ -562,7 +562,7 @@ rte_vhost_driver_attach_vdpa_device(const char *path, int
did)
{
struct vhost_user_socket *vsocket;
- if (rte_vdpa_get_device(did) == NULL)
+ if (rte_vdpa_get_device(did) == NULL || path == NULL)
return -1;
pthread_mutex_lock(&vhost_user.mutex);
diff --git a/lib/librte_vhost/vdpa.c b/lib/librte_vhost/vdpa.c
index 321e11f17..e91548843 100644
--- a/lib/librte_vhost/vdpa.c
+++ b/lib/librte_vhost/vdpa.c
@@ -49,7 +49,7 @@ rte_vdpa_register_device(struct rte_vdpa_dev_addr *addr,
char device_name[MAX_VDPA_NAME_LEN];
int i;
- if (vdpa_device_num >= MAX_VHOST_DEVICE)
+ if (vdpa_device_num >= MAX_VHOST_DEVICE || addr == NULL || ops == NULL)
return -1;
for (i = 0; i < MAX_VHOST_DEVICE; i++) {
@@ -99,6 +99,9 @@ rte_vdpa_find_device_id(struct rte_vdpa_dev_addr *addr)
struct rte_vdpa_device *dev;
int i;
+ if (addr == NULL)
+ return -1;
+
for (i = 0; i < MAX_VHOST_DEVICE; ++i) {
dev = vdpa_devices[i];
if (dev && is_same_vdpa_device(&dev->addr, addr))
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index e480aeac9..163f4595e 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -447,7 +447,7 @@ rte_vhost_get_mtu(int vid, uint16_t *mtu)
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || mtu == NULL)
return -ENODEV;
if (!(dev->flags & VIRTIO_DEV_READY))
@@ -515,7 +515,7 @@ rte_vhost_get_ifname(int vid, char *buf, size_t len)
{
struct virtio_net *dev = get_device(vid);
- if (dev == NULL)
+ if (dev == NULL || buf == NULL)
return -1;
len = RTE_MIN(len, sizeof(dev->ifname));
@@ -532,7 +532,7 @@ rte_vhost_get_negotiated_features(int vid, uint64_t
*features)
struct virtio_net *dev;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || features == NULL)
return -1;
*features = dev->features;
@@ -547,7 +547,7 @@ rte_vhost_get_mem_table(int vid, struct rte_vhost_memory
**mem)
size_t size;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || mem == NULL)
return -1;
size = dev->mem->nregions * sizeof(struct rte_vhost_mem_region);
@@ -570,7 +570,7 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
struct vhost_virtqueue *vq;
dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || vring == NULL)
return -1;
if (vring_idx >= VHOST_MAX_VRING)
@@ -763,7 +763,7 @@ int rte_vhost_get_log_base(int vid, uint64_t *log_base,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || log_base == NULL || log_size == NULL)
return -1;
*log_base = dev->log_base;
@@ -777,7 +777,7 @@ int rte_vhost_get_vring_base(int vid, uint16_t queue_id,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || last_avail_idx == NULL || last_used_idx == NULL)
return -1;
*last_avail_idx = dev->virtqueue[queue_id]->last_avail_idx;
@@ -805,7 +805,7 @@ int rte_vhost_extern_callback_register(int vid,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (dev == NULL || ops == NULL)
return -1;
dev->extern_ops = *ops;
--
2.17.1
Re: [dpdk-dev] [PATCH 1/3] ethdev: fix null pointer checking
On 03/04/2019 18:32, David Marchand wrote: On Wed, Apr 3, 2019 at 6:53 PM Ferruh Yigit <mailto:ferruh.yi...@intel.com>> wrote: On 4/3/2019 5:41 PM, Bruce Richardson wrote: > On Wed, Apr 03, 2019 at 05:35:22PM +0100, Ferruh Yigit wrote: >> On 4/3/2019 5:27 PM, Thomas Monjalon wrote: >>> 03/04/2019 18:07, Mohammad Abdul Awal: >>>> Null value for parameter name will cause segfault for the strnlen and >>>> strcmp functions. >>> >>> I'm not sure we want such obvious checks for all APIs. Here I would >>> say yes. >> >> These are internal functions, not APIs. I am for verifying input for >> (all) APIs but not for internal functions, drivers should call them and >> they are in our control, if they are passing NULL we can fix them :) >> > True, but if these are control path or init time code paths rather than > data path APIs, I don't see the harm in putting in the checks. No harm from performance point of view, agree, but also looks unnecessary to me. +1 All the more when you see the following patches that adds input checks in the faulty/too naive drivers. -- David Marchand Self-NACK to the patch considering the discussion above.
[dpdk-dev] [PATCH 2/3] net/virtio: fix null pointer checking
Null value of device name should return error without further processing.
Fixes: 1c8489da56 ("net/virtio-user: fix multi-process support")
Signed-off-by: Mohammad Abdul Awal
---
drivers/net/virtio/virtio_user_ethdev.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index 129c2b9ef..cefc6da66 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -516,6 +516,10 @@ virtio_user_pmd_probe(struct rte_vdev_device *dev)
if (rte_eal_process_type() == RTE_PROC_SECONDARY) {
const char *name = rte_vdev_device_name(dev);
+ if (name == NULL) {
+ RTE_LOG(ERR, PMD, "Device name is NULL\n");
+ return -1;
+ }
eth_dev = rte_eth_dev_attach_secondary(name);
if (!eth_dev) {
RTE_LOG(ERR, PMD, "Failed to probe %s\n", name);
--
2.17.1
[dpdk-dev] [PATCH 3/3] vhost: fix null pointer checking
Null value for parameters will cause segfault.
Fuxes: d7280c9fff ("vhost: support selective datapath")
Fixes: 72e8543093 ("vhost: add external message handling to the API")
Fixes: a277c71598 ("vhost: refactor code structure")
Fixes: ca33faf9ef ("vhost: introduce API to fetch negotiated features")
Fixes: eb32247457 ("vhost: export guest memory regions")
Fixes: 40ef286f23 ("vhost: export vhost vring info")
Fixes: bd2e0c3fe5 ("vhost: add APIs for live migration")
Fixes: 0b8572a0c1 ("vhost: add external message handling to the API")
Cc: sta...@dpdk.org
Signed-off-by: Mohammad Abdul Awal
---
lib/librte_vhost/vdpa.c | 5 -
lib/librte_vhost/vhost.c | 16
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/lib/librte_vhost/vdpa.c b/lib/librte_vhost/vdpa.c
index 321e11f17..814082479 100644
--- a/lib/librte_vhost/vdpa.c
+++ b/lib/librte_vhost/vdpa.c
@@ -49,7 +49,7 @@ rte_vdpa_register_device(struct rte_vdpa_dev_addr *addr,
char device_name[MAX_VDPA_NAME_LEN];
int i;
- if (vdpa_device_num >= MAX_VHOST_DEVICE)
+ if (vdpa_device_num >= MAX_VHOST_DEVICE || !addr || !ops)
return -1;
for (i = 0; i < MAX_VHOST_DEVICE; i++) {
@@ -99,6 +99,9 @@ rte_vdpa_find_device_id(struct rte_vdpa_dev_addr *addr)
struct rte_vdpa_device *dev;
int i;
+ if (!addr)
+ return -1;
+
for (i = 0; i < MAX_VHOST_DEVICE; ++i) {
dev = vdpa_devices[i];
if (dev && is_same_vdpa_device(&dev->addr, addr))
diff --git a/lib/librte_vhost/vhost.c b/lib/librte_vhost/vhost.c
index e480aeac9..27fe87188 100644
--- a/lib/librte_vhost/vhost.c
+++ b/lib/librte_vhost/vhost.c
@@ -447,7 +447,7 @@ rte_vhost_get_mtu(int vid, uint16_t *mtu)
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (!dev || !mtu)
return -ENODEV;
if (!(dev->flags & VIRTIO_DEV_READY))
@@ -515,7 +515,7 @@ rte_vhost_get_ifname(int vid, char *buf, size_t len)
{
struct virtio_net *dev = get_device(vid);
- if (dev == NULL)
+ if (dev == NULL || !buf)
return -1;
len = RTE_MIN(len, sizeof(dev->ifname));
@@ -532,7 +532,7 @@ rte_vhost_get_negotiated_features(int vid, uint64_t
*features)
struct virtio_net *dev;
dev = get_device(vid);
- if (!dev)
+ if (!dev || !features)
return -1;
*features = dev->features;
@@ -547,7 +547,7 @@ rte_vhost_get_mem_table(int vid, struct rte_vhost_memory
**mem)
size_t size;
dev = get_device(vid);
- if (!dev)
+ if (!dev || !mem)
return -1;
size = dev->mem->nregions * sizeof(struct rte_vhost_mem_region);
@@ -570,7 +570,7 @@ rte_vhost_get_vhost_vring(int vid, uint16_t vring_idx,
struct vhost_virtqueue *vq;
dev = get_device(vid);
- if (!dev)
+ if (!dev || !vring)
return -1;
if (vring_idx >= VHOST_MAX_VRING)
@@ -763,7 +763,7 @@ int rte_vhost_get_log_base(int vid, uint64_t *log_base,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (!dev || !log_base || !log_size)
return -1;
*log_base = dev->log_base;
@@ -777,7 +777,7 @@ int rte_vhost_get_vring_base(int vid, uint16_t queue_id,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (!dev || !last_avail_idx || !last_used_idx)
return -1;
*last_avail_idx = dev->virtqueue[queue_id]->last_avail_idx;
@@ -805,7 +805,7 @@ int rte_vhost_extern_callback_register(int vid,
{
struct virtio_net *dev = get_device(vid);
- if (!dev)
+ if (!dev || !ops)
return -1;
dev->extern_ops = *ops;
--
2.17.1
[dpdk-dev] [PATCH 1/3] ethdev: fix null pointer checking
Null value for parameter name will cause segfault for the
strnlen and strcmp functions.
Fixes: 0b33b68d12 ("ethdev: export allocate function")
Fixes: 942661004c ("ethdev: export secondary attach function")
Cc: sta...@dpdk.org
Signed-off-by: Mohammad Abdul Awal
---
lib/librte_ethdev/rte_ethdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lib/librte_ethdev/rte_ethdev.c b/lib/librte_ethdev/rte_ethdev.c
index 10bdfb37e..26898ed08 100644
--- a/lib/librte_ethdev/rte_ethdev.c
+++ b/lib/librte_ethdev/rte_ethdev.c
@@ -440,6 +440,11 @@ rte_eth_dev_allocate(const char *name)
struct rte_eth_dev *eth_dev = NULL;
size_t name_len;
+ if (name == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Null pointer is specified\n");
+ return NULL;
+ }
+
name_len = strnlen(name, RTE_ETH_NAME_MAX_LEN);
if (name_len == 0) {
RTE_ETHDEV_LOG(ERR, "Zero length Ethernet device name\n");
@@ -492,6 +497,11 @@ rte_eth_dev_attach_secondary(const char *name)
uint16_t i;
struct rte_eth_dev *eth_dev = NULL;
+ if (name == NULL) {
+ RTE_ETHDEV_LOG(ERR, "Null pointer is specified\n");
+ return NULL;
+ }
+
rte_eth_dev_shared_data_prepare();
/* Synchronize port attachment to primary port creation and release. */
--
2.17.1
Re: [dpdk-dev] [PATCH] doc: add deprecation notice to remove rte meter color
On 12/12/2018 16:38, Reshma Pattan wrote: Added deprecation notice to replace rte_meter_color with rte_color. Signed-off-by: Reshma Pattan Acked-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index b48486d36..bf1fdf369 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -105,3 +105,8 @@ Deprecation Notices - ``rte_pdump_set_socket_dir`` will be removed; - The parameter, ``path``, of ``rte_pdump_init`` will be removed; - The enum ``rte_pdump_socktype`` will be removed. + +* meter: New ``rte_color`` definition will be added in 19.02 and that will + replace ``enum rte_meter_color`` in meter library in 19.05. This will help + to consolidate color definition, which is currently replicated in many places, + such as: rte_meter.h, rte_mtr.h, rte_tm.h. Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v2 1/9] cryptodev: add opaque userdata pointer into crypto sym session
On 30/11/2018 16:45, Konstantin Ananyev wrote:
Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev
---
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..009860e7b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
__extension__ void *sess_private_data[0];
/**< Private symmetric session material */
};
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v2 2/9] security: add opaque userdata pointer into security session
On 30/11/2018 16:45, Konstantin Ananyev wrote:
Add 'uint64_t opaque_data' inside struct rte_security_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev
---
lib/librte_security/rte_security.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_security/rte_security.h
b/lib/librte_security/rte_security.h
index 1431b4df1..07b315512 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -318,6 +318,8 @@ struct rte_security_session_conf {
struct rte_security_session {
void *sess_private_data;
/**< Private session material */
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
};
/**
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v2 3/9] net: add ESP trailer structure definition
On 30/11/2018 16:46, Konstantin Ananyev wrote:
Signed-off-by: Konstantin Ananyev
---
lib/librte_net/rte_esp.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_esp.h b/lib/librte_net/rte_esp.h
index f77ec2eb2..8e1b3d2dd 100644
--- a/lib/librte_net/rte_esp.h
+++ b/lib/librte_net/rte_esp.h
@@ -11,7 +11,7 @@
* ESP-related defines
*/
-#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -25,6 +25,14 @@ struct esp_hdr {
rte_be32_t seq; /**< packet sequence number */
} __attribute__((__packed__));
+/**
+ * ESP Trailer
+ */
+struct esp_tail {
+ uint8_t pad_len; /**< number of pad bytes (0-255) */
+ uint8_t next_proto; /**< IPv4 or IPv6 or next layer header */
+} __attribute__((__packed__));
+
#ifdef __cplusplus
}
#endif
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH] doc: deprecation notice for sched API change
On 14/11/2018 15:36, Jasvinder Singh wrote: There will be change in API functions because of mbuf sched field updates, outlined in deprecation note of mbuf->hash.sched. Signed-off-by: Jasvinder Singh Acked-by: Cristian Dumitrescu --- doc/guides/rel_notes/deprecation.rst | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 34b28234c..b54598d07 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -34,6 +34,11 @@ Deprecation Notices is defined in librte_sched in a non-generic way. The new generic format will contain: queue ID, traffic class, color. Field size will not change. +* sched: Some API functions will change prototype due to the above + deprecation note for mbuf->hash.sched, e.g. rte_sched_port_pkt_write() and + rte_sched_port_pkt_read() will likely have an additional parameter + of type struct rte_sched_port. + * mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As ``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()`` Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH 2/9] security: add opaque userdata pointer into security session
On 15/11/2018 23:53, Konstantin Ananyev wrote:
Add 'uint64_t opaque_data' inside struct rte_security_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev
---
lib/librte_security/rte_security.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_security/rte_security.h
b/lib/librte_security/rte_security.h
index 1431b4df1..07b315512 100644
--- a/lib/librte_security/rte_security.h
+++ b/lib/librte_security/rte_security.h
@@ -318,6 +318,8 @@ struct rte_security_session_conf {
struct rte_security_session {
void *sess_private_data;
/**< Private session material */
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
};
/**
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH 1/9] cryptodev: add opaque userdata pointer into crypto sym session
On 15/11/2018 23:53, Konstantin Ananyev wrote:
Add 'uint64_t opaque_data' inside struct rte_cryptodev_sym_session.
That allows upper layer to easily associate some user defined
data with the session.
Signed-off-by: Konstantin Ananyev
---
lib/librte_cryptodev/rte_cryptodev.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_cryptodev/rte_cryptodev.h
b/lib/librte_cryptodev/rte_cryptodev.h
index 4099823f1..009860e7b 100644
--- a/lib/librte_cryptodev/rte_cryptodev.h
+++ b/lib/librte_cryptodev/rte_cryptodev.h
@@ -954,6 +954,8 @@ rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id,
* has a fixed algo, key, op-type, digest_len etc.
*/
struct rte_cryptodev_sym_session {
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
__extension__ void *sess_private_data[0];
/**< Private symmetric session material */
};
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH 3/9] net: add ESP trailer structure definition
On 15/11/2018 23:53, Konstantin Ananyev wrote:
Signed-off-by: Konstantin Ananyev
---
lib/librte_net/rte_esp.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/librte_net/rte_esp.h b/lib/librte_net/rte_esp.h
index f77ec2eb2..8e1b3d2dd 100644
--- a/lib/librte_net/rte_esp.h
+++ b/lib/librte_net/rte_esp.h
@@ -11,7 +11,7 @@
* ESP-related defines
*/
-#include
+#include
#ifdef __cplusplus
extern "C" {
@@ -25,6 +25,14 @@ struct esp_hdr {
rte_be32_t seq; /**< packet sequence number */
} __attribute__((__packed__));
+/**
+ * ESP Trailer
+ */
+struct esp_tail {
+ uint8_t pad_len; /**< number of pad bytes (0-255) */
+ uint8_t next_proto; /**< IPv4 or IPv6 or next layer header */
+} __attribute__((__packed__));
+
#ifdef __cplusplus
}
#endif
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH] doc: security deprecation notice for session changes
On 14/11/2018 11:23, Konstantin Ananyev wrote:
Add 'uint64_t opaque_data' inside struct rte_security_session.
That allows upper layer to easily associate some user defined
data with the session.
Proposed new layout for:
struct rte_security_session {
void *sess_private_data;
/**< Private session material */
+ uint64_t opaque_data;
+ /**< Opaque user defined data */
};
Signed-off-by: Konstantin Ananyev
---
doc/guides/rel_notes/deprecation.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_notes/deprecation.rst
b/doc/guides/rel_notes/deprecation.rst
index 34b28234c..0cdc42842 100644
--- a/doc/guides/rel_notes/deprecation.rst
+++ b/doc/guides/rel_notes/deprecation.rst
@@ -55,3 +55,9 @@ Deprecation Notices
- ``rte_pdump_set_socket_dir`` will be removed;
- The parameter, ``path``, of ``rte_pdump_init`` will be removed;
- The enum ``rte_pdump_socktype`` will be removed.
+
+* security: ABI change:
+
+ New field ``uint64_t opaque_data`` is planned to add into
+ ``rte_security_session`` structure. That would allow upper layer to easily
+ associate/de-associate some user defined data with the security session.
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v2 3/3] ethdev: remove vxlan and nvgre encapsulation commands
xlan_encap action structure.
-*
-* See struct rte_flow_action_vxlan_encap.
-*/
- RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP,
-
- /**
-* Decapsulate outer most VXLAN tunnel from matched flow.
-*
-* If flow pattern does not define a valid VXLAN tunnel (as specified by
-* RFC7348) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION
-* error.
-*/
- RTE_FLOW_ACTION_TYPE_VXLAN_DECAP,
-
- /**
-* Encapsulate flow in NVGRE tunnel defined in the
-* rte_flow_action_nvgre_encap action structure.
-*
-* See struct rte_flow_action_nvgre_encap.
-*/
- RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP,
-
- /**
-* Decapsulate outer most NVGRE tunnel from matched flow.
-*
-* If flow pattern does not define a valid NVGRE tunnel (as specified by
-* RFC7637) then the PMD should return a RTE_FLOW_ERROR_TYPE_ACTION
-* error.
-*/
- RTE_FLOW_ACTION_TYPE_NVGRE_DECAP,
-
- /**
* Encapsulate the packet with tunnel header as defined in
* rte_flow_action_tunnel_encap action structure.
*
@@ -1837,75 +1803,6 @@ struct rte_flow_action_of_push_mpls {
* @warning
* @b EXPERIMENTAL: this structure may change without prior notice
*
- * RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP
- *
- * VXLAN tunnel end-point encapsulation data definition
- *
- * The tunnel definition is provided through the flow item pattern, the
- * provided pattern must conform to RFC7348 for the tunnel specified. The flow
- * definition must be provided in order from the RTE_FLOW_ITEM_TYPE_ETH
- * definition up the end item which is specified by RTE_FLOW_ITEM_TYPE_END.
- *
- * The mask field allows user to specify which fields in the flow item
- * definitions can be ignored and which have valid data and can be used
- * verbatim.
- *
- * Note: the last field is not used in the definition of a tunnel and can be
- * ignored.
- *
- * Valid flow definition for RTE_FLOW_ACTION_TYPE_VXLAN_ENCAP include:
- *
- * - ETH / IPV4 / UDP / VXLAN / END
- * - ETH / IPV6 / UDP / VXLAN / END
- * - ETH / VLAN / IPV4 / UDP / VXLAN / END
- *
- */
-struct rte_flow_action_vxlan_encap {
- /**
-* Encapsulating vxlan tunnel definition
-* (terminated by the END pattern item).
-*/
- struct rte_flow_item *definition;
-};
-
-/**
- * @warning
- * @b EXPERIMENTAL: this structure may change without prior notice
- *
- * RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP
- *
- * NVGRE tunnel end-point encapsulation data definition
- *
- * The tunnel definition is provided through the flow item pattern the
- * provided pattern must conform with RFC7637. The flow definition must be
- * provided in order from the RTE_FLOW_ITEM_TYPE_ETH definition up the end item
- * which is specified by RTE_FLOW_ITEM_TYPE_END.
- *
- * The mask field allows user to specify which fields in the flow item
- * definitions can be ignored and which have valid data and can be used
- * verbatim.
- *
- * Note: the last field is not used in the definition of a tunnel and can be
- * ignored.
- *
- * Valid flow definition for RTE_FLOW_ACTION_TYPE_NVGRE_ENCAP include:
- *
- * - ETH / IPV4 / NVGRE / END
- * - ETH / VLAN / IPV6 / NVGRE / END
- *
- */
-struct rte_flow_action_nvgre_encap {
- /**
-* Encapsulating vxlan tunnel definition
-* (terminated by the END pattern item).
-*/
- struct rte_flow_item *definition;
-};
-
-/**
- * @warning
- * @b EXPERIMENTAL: this structure may change without prior notice
- *
* RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP
*
* Tunnel end-point encapsulation data definition
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v8 2/2] app/testpmd: add NVGRE encap/decap support
uides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1552,6 +1552,21 @@ flow rule using the action vxlan_encap will use the last
configuration set.
To have a different encapsulation header, one of those commands must be called
before the flow rule creation.
+Config NVGRE Encap outer layers
+~~~
+
+Configure the outer layer to encapsulate a packet inside a NVGRE tunnel::
+
+ set nvgre ip-version (ipv4|ipv6) tni (tni) ip-src (ip-src) ip-dst (ip-dst) \
+eth-src (eth-src) eth-dst (eth-dst)
+ set nvgre-with-vlan ip-version (ipv4|ipv6) tni (tni) ip-src (ip-src) \
+ip-dst (ip-dst) vlan-tci (vlan-tci) eth-src (eth-src) eth-dst (eth-dst)
^^^
Auto-completion suggestion for values should be wrapped between '<' and
'>', not '(' and ')', for all cases.
+
+Those command will set an internal configuration inside testpmd, any following
+flow rule using the action nvgre_encap will use the last configuration set.
+To have a different encapsulation header, one of those commands must be called
+before the flow rule creation.
+
Port Functions
--
@@ -3673,6 +3688,12 @@ This section lists supported actions and their attributes, if any.
- ``vxlan_decap``: Performs a decapsulation action by stripping all headers of
the VXLAN tunnel network overlay from the matched flow.
+- ``nvgre_encap``: Performs a NVGRE encapsulation, outer layer configuration
+ is done through `Config NVGRE Encap outer layers`_.
+
+- ``nvgre_decap``: Performs a decapsulation action by stripping all headers of
+ the NVGRE tunnel network overlay from the matched flow.
+
Destroying flow rules
~
@@ -3970,6 +3991,37 @@ IPv6 VXLAN outer header::
testpmd> flow create 0 ingress pattern end actions vxlan_encap /
queue index 0 / end
+Sample NVGRE encapsulation rule
+~~~
+
+NVGRE encapsulation outer layer has default value pre-configured in testpmd
+source code, those can be changed by using the following commands
+
+IPv4 NVGRE outer header::
+
+ testpmd> set nvgre ip-version ipv4 tni 4 ip-src 127.0.0.1 ip-dst 128.0.0.1
+eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions nvgre_encap /
+queue index 0 / end
+
+ testpmd> set nvgre-with-vlan ip-version ipv4 tni 4 ip-src 127.0.0.1
+ ip-dst 128.0.0.1 vlan-tci 34 eth-src 11:11:11:11:11:11
+ eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions nvgre_encap /
+ queue index 0 / end
+
+IPv6 NVGRE outer header::
+
+ testpmd> set nvgre ip-version ipv6 tni 4 ip-src ::1 ip-dst ::
+eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions nvgre_encap /
+queue index 0 / end
+
+ testpmd> set nvgre-with-vlan ip-version ipv6 tni 4 ip-src ::1 ip-dst ::
+vlan-tci 34 eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions nvgre_encap /
+queue index 0 / end
+
BPF Functions
--
Tested-by: Mohammad Abdul Awal
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v8 1/2] app/testpmd: add VXLAN encap/decap support
.select_vlan = 0,
+ .vni = "\x00\x00\x00",
+ .udp_src = 0,
+ .udp_dst = RTE_BE16(4789),
+ .ipv4_src = IPv4(127, 0, 0, 1),
+ .ipv4_dst = IPv4(255, 255, 255, 255),
+ .ipv6_src = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x00\x01",
+ .ipv6_dst = "\x00\x00\x00\x00\x00\x00\x00\x00"
+ "\x00\x00\x00\x00\x00\x00\x11\x11",
+ .vlan_tci = 0,
+ .eth_src = "\x00\x00\x00\x00\x00\x00",
+ .eth_dst = "\xff\xff\xff\xff\xff\xff",
+};
+
/* Forward function declarations */
static void map_port_queue_stats_mapping_registers(portid_t pi,
struct rte_port *port);
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index f51cd9dd9..0d6618788 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -479,6 +479,23 @@ struct gso_status {
extern struct gso_status gso_ports[RTE_MAX_ETHPORTS];
extern uint16_t gso_max_segment_size;
+/* VXLAN encap/decap parameters. */
+struct vxlan_encap_conf {
+ uint32_t select_ipv4:1;
+ uint32_t select_vlan:1;
+ uint8_t vni[3];
+ rte_be16_t udp_src;
+ rte_be16_t udp_dst;
+ rte_be32_t ipv4_src;
+ rte_be32_t ipv4_dst;
+ uint8_t ipv6_src[16];
+ uint8_t ipv6_dst[16];
+ rte_be16_t vlan_tci;
+ uint8_t eth_src[ETHER_ADDR_LEN];
+ uint8_t eth_dst[ETHER_ADDR_LEN];
+};
+struct vxlan_encap_conf vxlan_encap_conf;
+
static inline unsigned int
lcore_num(void)
{
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 0d6fd50ca..3281778d9 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -1534,6 +1534,23 @@ Enable or disable a per queue Tx offloading only on a
specific Tx queue::
This command should be run when the port is stopped, or else it will fail.
+Config VXLAN Encap outer layers
+~~~
+
+Configure the outer layer to encapsulate a packet inside a VXLAN tunnel::
+
+ set vxlan ip-version (ipv4|ipv6) vni (vni) udp-src (udp-src) \
+ udp-dst (udp-dst) ip-src (ip-src) ip-dst (ip-dst) eth-src (eth-src) \
+ eth-dst (eth-dst)
+
+ set vxlan-with-vlan ip-version (ipv4|ipv6) vni (vni) udp-src (udp-src) \
+ udp-dst (udp-dst) ip-src (ip-src) ip-dst (ip-dst) vlan-tci (vlan-tci) \
+ eth-src (eth-src) eth-dst (eth-dst)
+
+Those command will set an internal configuration inside testpmd, any following
+flow rule using the action vxlan_encap will use the last configuration set.
+To have a different encapsulation header, one of those commands must be called
+before the flow rule creation.
Port Functions
--
@@ -3650,6 +3667,12 @@ This section lists supported actions and their
attributes, if any.
- ``ethertype``: Ethertype.
+- ``vxlan_encap``: Performs a VXLAN encapsulation, outer layer configuration
+ is done through `Config VXLAN Encap outer layers`_.
+
+- ``vxlan_decap``: Performs a decapsulation action by stripping all headers of
+ the VXLAN tunnel network overlay from the matched flow.
+
Destroying flow rules
~
@@ -3915,6 +3938,38 @@ Validate and create a QinQ rule on port 0 to steer traffic to a queue on the hos
0 0 0 i- ETH VLAN VLAN=>VF QUEUE
1 0 0 i- ETH VLAN VLAN=>PF QUEUE
+Sample VXLAN encapsulation rule
+~~~
+
+VXLAN encapsulation outer layer has default value pre-configured in testpmd
+source code, those can be changed by using the following commands
+
+IPv4 VXLAN outer header::
+
+ testpmd> set vxlan ip-version ipv4 vni 4 udp-src 4 udp-dst 4 ip-src 127.0.0.1
+ip-dst 128.0.0.1 eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions vxlan_encap /
+queue index 0 / end
+
+ testpmd> set vxlan-with-vlan ip-version ipv4 vni 4 udp-src 4 udp-dst 4 ip-src
+ 127.0.0.1 ip-dst 128.0.0.1 vlan-tci 34 eth-src 11:11:11:11:11:11
+ eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions vxlan_encap /
+ queue index 0 / end
+
+IPv6 VXLAN outer header::
+
+ testpmd> set vxlan ip-version ipv6 vni 4 udp-src 4 udp-dst 4 ip-src ::1
+ip-dst :: eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions vxlan_encap /
+ queue index 0 / end
+
+ testpmd> set vxlan-with-vlan ip-version ipv6 vni 4 udp-src 4 udp-dst 4
+ ip-src ::1 ip-dst :: vlan-tci 34 eth-src 11:11:11:11:11:11
+ eth-dst 22:22:22:22:22:22
+ testpmd> flow create 0 ingress pattern end actions vxlan_encap /
+ queue index 0 / end
+
BPF Functions
--
Tested-by: Mohammad Abdul Awal
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v8 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap
On 05/07/2018 15:33, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ip-version ipv4 vni 4 udp-src 4 udp-dst 4 ip-src 27.0.0.1
ip-dst 128.0.0.1 eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap /
queue index 0 / end
set vxlan-with-vlan ip-version ipv4 vni 4 udp-src 4 udp-dst 4 p-src
127.0.0.1 ip-dst 128.0.0.1 vlan-tci 34 eth-src 11:11:11:11:11:11
eth-dst 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap /
queue index 0 / end
set vxlan ip-version ipv6 vni 4 udp-src 4 udp-dst 4 ip-src ::1
ip-dst :: eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap /
queue index 0 / end
set vxlan-with-vlan ip-version ipv6 vni 4 udp-src 4 udp-dst 4
ip-src ::1 ip-dst :: vlan-tci 34 eth-src 11:11:11:11:11:11
eth-dst 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap /
queue index 0 / end
This also replace the proposal done by Mohammad Abdul Awal [1] which handles
in a more complex way for the same work.
Note this API has already a modification planned for 18.11 [2] thus those
series should have a limited life for a single release.
[1] https://dpdk.org/ml/archives/dev/2018-May/101403.html
[2] https://dpdk.org/ml/archives/dev/2018-June/103485.html
Changes in v8:
- add static tokens in the command line to be user friendly.
Changes in v7:
- add missing documentation added in v5 and removed in v6 by mistake.
Changes in v6:
- fix compilation under redhat 7.5 with gcc 4.8.5 20150623
Changes in v5:
- fix documentation generation.
- add more explanation on how to generate several encapsulated flows.
Changes in v4:
- fix big endian issue on vni and tni.
- add samples to the documentation.
- set the VXLAN UDP source port to 0 by default to let the driver generate it
from the inner hash as described in the RFC 7348.
- use default rte flow mask for each item.
Changes in v3:
- support VLAN in the outer encapsulation.
- fix the documentation with missing arguments.
Changes in v2:
- add default IPv6 values for NVGRE encapsulation.
- replace VXLAN to NVGRE in comments concerning NVGRE layer.
Nelio Laranjeiro (2):
app/testpmd: add VXLAN encap/decap support
app/testpmd: add NVGRE encap/decap support
app/test-pmd/cmdline.c | 345
app/test-pmd/cmdline_flow.c | 274
app/test-pmd/testpmd.c | 32 ++
app/test-pmd/testpmd.h | 32 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 107 ++
5 files changed, 790 insertions(+)
Looks good to me.
Tested-by: Mohammad Abdul Awal
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v7 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap
On 27/06/2018 12:45, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
set vxlan ipv6 4 4 4 ::1 :: 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
set nvgre ipv4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions nvgre_encap / queue index 0 / end
set nvgre ipv6 4 ::1 :: 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions nvgre_encap / queue index 0 / end
This also replace the proposal done by Mohammad Abdul Awal [1] which handles
in a more complex way for the same work.
Note this API has already a modification planned for 18.11 [2] thus those
series should have a limited life for a single release.
[1] https://dpdk.org/ml/archives/dev/2018-May/101403.html
[2] https://dpdk.org/ml/archives/dev/2018-June/103485.html
Changes in v7:
- add missing documentation added in v5 and removed in v6 by mistake.
Changes in v6:
- fix compilation under redhat 7.5 with gcc 4.8.5 20150623
Changes in v5:
- fix documentation generation.
- add more explanation on how to generate several encapsulated flows.
Changes in v4:
- fix big endian issue on vni and tni.
- add samples to the documentation.
- set the VXLAN UDP source port to 0 by default to let the driver generate it
from the inner hash as described in the RFC 7348.
- use default rte flow mask for each item.
Changes in v3:
- support VLAN in the outer encapsulation.
- fix the documentation with missing arguments.
Changes in v2:
- add default IPv6 values for NVGRE encapsulation.
- replace VXLAN to NVGRE in comments concerning NVGRE layer.
Nelio Laranjeiro (2):
app/testpmd: add VXLAN encap/decap support
app/testpmd: add NVGRE encap/decap support
app/test-pmd/cmdline.c | 252 ++
app/test-pmd/cmdline_flow.c | 274
app/test-pmd/testpmd.c | 32 +++
app/test-pmd/testpmd.h | 32 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 82 ++
5 files changed, 672 insertions(+)
Hi,
I have one concern in terms of usability though.
In testpmd, the rte_flow command line options have auto-completion with
" " format which make using the command very
much user friendly.
For the command "set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1
11:11:11:11:11:11 22:22:22:22:22:22", it does not look much user
friendly to me. A user may easily lose track of sequence of 9 param
items. It would be much user friendly if the options would be like below
and has auto-completion.
set vxlan ip_ver vni udp_src
udp-dst ip_src ip_dst
eth_src eth_dst
This way an user may never feel confused. Can maintainers comment on
this point please?
Regards,
Awal.
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap
On 22/06/2018 10:08, Nélio Laranjeiro wrote:
On Fri, Jun 22, 2018 at 09:51:15AM +0100, Mohammad Abdul Awal wrote:
On 22/06/2018 09:31, Nélio Laranjeiro wrote:
On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote:
Hi Nelio,
On 21/06/2018 08:13, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
This way we can define only one tunnel for all the flows. This is not a
convenient for testing a scenario (e.g. mutiport or switch) with multiple
tunnels. Isn't it?
Hi Awal.
The "set vxlan" command will just configure the outer VXLAN tunnel to be
used, when the "flow" command is invoked, it will use the VXLAN tunnel
information and create a valid VXLAN_ENCAP action. For instance:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
testpmd> set vxlan ipv6 4 34 42 ::1 :: 80:12:13:14:15:16
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one
with an IPv6. Whereas:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end
actions vxlan_encap / queue index 0 / end
testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end
actions vxlan_encap / queue index 0 / end
will encapsulate the packets having as IPv4 source IP 10.2.3.4 and
20.2.3.4 with the same VXLAN tunnel headers.
I understand that the same IPv4 tunnel will be used for both flows in your
example above. I have the following questions.
1) How can we create two or more IPv4 (or IPv6) tunnel?
1) How can we make the flows to use different IPv4 tunnels?
As an example,
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33
44:44:44:44:44:44
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
Doing this, the flows will use the same tunnel, you must do:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33
44:44:44:44:44:44
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
to have what you want.
OK, thanks for the clarification. So, since there will be only one
global instance of the tunnel, for any subsequent "set vxlan"
operations, the tunnel created from the last last operation will be
used. May be it should be cleared in the description/documentation?
Is it possible?
Regards,
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap
On 22/06/2018 09:31, Nélio Laranjeiro wrote:
On Fri, Jun 22, 2018 at 08:42:10AM +0100, Mohammad Abdul Awal wrote:
Hi Nelio,
On 21/06/2018 08:13, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
This way we can define only one tunnel for all the flows. This is not a
convenient for testing a scenario (e.g. mutiport or switch) with multiple
tunnels. Isn't it?
Hi Awal.
The "set vxlan" command will just configure the outer VXLAN tunnel to be
used, when the "flow" command is invoked, it will use the VXLAN tunnel
information and create a valid VXLAN_ENCAP action. For instance:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
testpmd> set vxlan ipv6 4 34 42 ::1 :: 80:12:13:14:15:16 22:22:22:22:22:22
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index
0 / end
will create two VLXAN_ENCAP flow one with IPv4 tunnel the second one
with an IPv6. Whereas:
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.2.3.4 / end
actions vxlan_encap / queue index 0 / end
testpmd> flow create 0 ingress pattern eth / ipv4 src is 20.2.3.4 / end
actions vxlan_encap / queue index 0 / end
will encapsulate the packets having as IPv4 source IP 10.2.3.4 and
20.2.3.4 with the same VXLAN tunnel headers.
I understand that the same IPv4 tunnel will be used for both flows in
your example above. I have the following questions.
1) How can we create two or more IPv4 (or IPv6) tunnel?
1) How can we make the flows to use different IPv4 tunnels?
As an example,
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11
22:22:22:22:22:22
testpmd> set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 33:33:33:33:33:33
44:44:44:44:44:44
testpmd> flow create 0 ingress pattern end actions vxlan_encap
/ queue index 0 / end
testpmd> flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
Is it possible?
Regards,
Awal.
Regards,
Re: [dpdk-dev] [PATCH v4 0/2] app/testpmd implement VXLAN/NVGRE Encap/Decap
Hi Nelio,
On 21/06/2018 08:13, Nelio Laranjeiro wrote:
This series adds an easy and maintainable configuration version support for
those two actions for 18.08 by using global variables in testpmd to store the
necessary information for the tunnel encapsulation. Those variables are used
in conjunction of RTE_FLOW_ACTION_{VXLAN,NVGRE}_ENCAP action to create easily
the action for flows.
A common way to use it:
set vxlan ipv4 4 4 4 127.0.0.1 128.0.0.1 11:11:11:11:11:11 22:22:22:22:22:22
flow create 0 ingress pattern end actions vxlan_encap / queue index 0 / end
This way we can define only one tunnel for all the flows. This is not a
convenient for testing a scenario (e.g. mutiport or switch) with
multiple tunnels. Isn't it?
Regards,
Awal.
Re: [dpdk-dev] [PATCH v2 1/2] app/testpmd: add VXLAN encap/decap support
Hi Nelio,
On 18/06/2018 09:52, Nelio Laranjeiro wrote:
Due to the complex VXLAN_ENCAP flow action and based on the fact testpmd
does not allocate memory, this patch adds a new command in testpmd to
initialise a global structure containing the necessary information to
make the outer layer of the packet. This same global structure will
then be used by the flow command line in testpmd when the action
vxlan_encap will be parsed, at this point, the conversion into such
action becomes trivial.
This global structure is only used for the encap action.
Signed-off-by: Nelio Laranjeiro
---
app/test-pmd/cmdline.c | 90 ++
app/test-pmd/cmdline_flow.c | 129
app/test-pmd/testpmd.c | 15 +++
app/test-pmd/testpmd.h | 15 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 12 ++
5 files changed, 261 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 27e2aa8c8..a3b98b2f2 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -781,6 +781,10 @@ static void cmd_help_long_parsed(void *parsed_result,
"port tm hierarchy commit (port_id) (clean_on_fail)\n"
" Commit tm hierarchy.\n\n"
+ "vxlan ipv4|ipv6 vni udp-src udp-dst ip-src ip-dst"
+ " eth-src eth-dst\n"
+ " Configure the VXLAN encapsulation for
flows.\n\n"
+
Should there be support for outer VLAN header according to the definitions?
, list_pkt_forwarding_modes()
);
}
@@ -14838,6 +14842,91 @@ cmdline_parse_inst_t cmd_set_port_tm_hierarchy_default
= {
};
#endif
+/** Set VXLAN encapsulation details */
+struct cmd_set_vxlan_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t vxlan;
+ cmdline_fixed_string_t ip_version;
+ uint32_t vni;
+ uint16_t udp_src;
+ uint16_t udp_dst;
+ cmdline_ipaddr_t ip_src;
+ cmdline_ipaddr_t ip_dst;
+ struct ether_addr eth_src;
+ struct ether_addr eth_dst;
+};
+
+cmdline_parse_token_string_t cmd_set_vxlan_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, set, "set");
+cmdline_parse_token_string_t cmd_set_vxlan_vxlan =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, vxlan, "vxlan");
+cmdline_parse_token_string_t cmd_set_vxlan_ip_version =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_vxlan_result, ip_version,
+"ipv4#ipv6");
+cmdline_parse_token_num_t cmd_set_vxlan_vni =
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, vni, UINT32);
+cmdline_parse_token_num_t cmd_set_vxlan_udp_src =
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_src, UINT16);
+cmdline_parse_token_num_t cmd_set_vxlan_udp_dst =
+ TOKEN_NUM_INITIALIZER(struct cmd_set_vxlan_result, udp_dst, UINT16);
+cmdline_parse_token_ipaddr_t cmd_set_vxlan_ip_src =
+ TOKEN_IPADDR_INITIALIZER(struct cmd_set_vxlan_result, ip_src);
+cmdline_parse_token_ipaddr_t cmd_set_vxlan_ip_dst =
+ TOKEN_IPADDR_INITIALIZER(struct cmd_set_vxlan_result, ip_dst);
+cmdline_parse_token_etheraddr_t cmd_set_vxlan_eth_src =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vxlan_result, eth_src);
+cmdline_parse_token_etheraddr_t cmd_set_vxlan_eth_dst =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_vxlan_result, eth_dst);
+
+static void cmd_set_vxlan_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_set_vxlan_result *res = parsed_result;
+ uint32_t vni = rte_cpu_to_be_32(res->vni) >> 8;
+
+ if (strcmp(res->ip_version, "ipv4") == 0)
+ vxlan_encap_conf.select_ipv4 = 1;
+ else if (strcmp(res->ip_version, "ipv6") == 0)
+ vxlan_encap_conf.select_ipv4 = 0;
+ else
+ return;
+ memcpy(vxlan_encap_conf.vni, &vni, 3);
+ vxlan_encap_conf.udp_src = rte_cpu_to_be_16(res->udp_src);
+ vxlan_encap_conf.udp_dst = rte_cpu_to_be_16(res->udp_dst);
+ if (vxlan_encap_conf.select_ipv4) {
+ IPV4_ADDR_TO_UINT(res->ip_src, vxlan_encap_conf.ipv4_src);
+ IPV4_ADDR_TO_UINT(res->ip_dst, vxlan_encap_conf.ipv4_dst);
+ } else {
+ IPV6_ADDR_TO_ARRAY(res->ip_src, vxlan_encap_conf.ipv6_src);
+ IPV6_ADDR_TO_ARRAY(res->ip_dst, vxlan_encap_conf.ipv6_dst);
+ }
+ memcpy(vxlan_encap_conf.eth_src, res->eth_src.addr_bytes,
+ ETHER_ADDR_LEN);
+ memcpy(vxlan_encap_conf.eth_dst, res->eth_dst.addr_bytes,
+ ETHER_ADDR_LEN);
+}
+
+cmdline_parse_inst_t cmd_set_vxlan = {
+ .f = cmd_set_vxlan_parsed,
+ .data = NULL,
+ .help_str = "set vxlan ipv4|ipv6"
+ " ",
+ .tokens = {
+ (void *)&cmd_set_vxlan_set,
+ (voi
Re: [dpdk-dev] [PATCH v2 2/2] app/testpmd: add NVGRE encap/decap support
On 18/06/2018 09:52, Nelio Laranjeiro wrote:
Due to the complex NVGRE_ENCAP flow action and based on the fact testpmd
does not allocate memory, this patch adds a new command in testpmd to
initialise a global structure containing the necessary information to
make the outer layer of the packet. This same global structure will
then be used by the flow command line in testpmd when the action
nvgre_encap will be parsed, at this point, the conversion into such
action becomes trivial.
This global structure is only used for the encap action.
Signed-off-by: Nelio Laranjeiro
---
app/test-pmd/cmdline.c | 79 +
app/test-pmd/cmdline_flow.c | 119
app/test-pmd/testpmd.c | 13 +++
app/test-pmd/testpmd.h | 13 +++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 13 +++
5 files changed, 237 insertions(+)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index a3b98b2f2..7ea1e5792 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -785,6 +785,9 @@ static void cmd_help_long_parsed(void *parsed_result,
" eth-src eth-dst\n"
" Configure the VXLAN encapsulation for
flows.\n\n"
+ "nvgre ipv4|ipv6 tni ip-src ip-dst eth-src eth-dst\n"
+ " Configure the NVGRE encapsulation for
flows.\n\n"
Should there be support for outer VLAN header according to the definitions?
+
, list_pkt_forwarding_modes()
);
}
@@ -14927,6 +14930,81 @@ cmdline_parse_inst_t cmd_set_vxlan = {
},
};
+/** Set NVGRE encapsulation details */
+struct cmd_set_nvgre_result {
+ cmdline_fixed_string_t set;
+ cmdline_fixed_string_t nvgre;
+ cmdline_fixed_string_t ip_version;
+ uint32_t tni;
+ cmdline_ipaddr_t ip_src;
+ cmdline_ipaddr_t ip_dst;
+ struct ether_addr eth_src;
+ struct ether_addr eth_dst;
+};
+
+cmdline_parse_token_string_t cmd_set_nvgre_set =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, set, "set");
+cmdline_parse_token_string_t cmd_set_nvgre_nvgre =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, nvgre, "nvgre");
+cmdline_parse_token_string_t cmd_set_nvgre_ip_version =
+ TOKEN_STRING_INITIALIZER(struct cmd_set_nvgre_result, ip_version,
+"ipv4#ipv6");
+cmdline_parse_token_num_t cmd_set_nvgre_tni =
+ TOKEN_NUM_INITIALIZER(struct cmd_set_nvgre_result, tni, UINT32);
+cmdline_parse_token_num_t cmd_set_nvgre_ip_src =
+ TOKEN_IPADDR_INITIALIZER(struct cmd_set_nvgre_result, ip_src);
+cmdline_parse_token_ipaddr_t cmd_set_nvgre_ip_dst =
+ TOKEN_IPADDR_INITIALIZER(struct cmd_set_nvgre_result, ip_dst);
+cmdline_parse_token_etheraddr_t cmd_set_nvgre_eth_src =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_nvgre_result, eth_src);
+cmdline_parse_token_etheraddr_t cmd_set_nvgre_eth_dst =
+ TOKEN_ETHERADDR_INITIALIZER(struct cmd_set_nvgre_result, eth_dst);
+
+static void cmd_set_nvgre_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_set_nvgre_result *res = parsed_result;
+ uint32_t tni = rte_cpu_to_be_32(res->tni) >> 8;
+
+ if (strcmp(res->ip_version, "ipv4") == 0)
+ nvgre_encap_conf.select_ipv4 = 1;
+ else if (strcmp(res->ip_version, "ipv6") == 0)
+ nvgre_encap_conf.select_ipv4 = 0;
+ else
+ return;
+ memcpy(nvgre_encap_conf.tni, &tni, 3);
+ if (nvgre_encap_conf.select_ipv4) {
+ IPV4_ADDR_TO_UINT(res->ip_src, nvgre_encap_conf.ipv4_src);
+ IPV4_ADDR_TO_UINT(res->ip_dst, nvgre_encap_conf.ipv4_dst);
+ } else {
+ IPV6_ADDR_TO_ARRAY(res->ip_src, nvgre_encap_conf.ipv6_src);
+ IPV6_ADDR_TO_ARRAY(res->ip_dst, nvgre_encap_conf.ipv6_dst);
+ }
+ memcpy(nvgre_encap_conf.eth_src, res->eth_src.addr_bytes,
+ ETHER_ADDR_LEN);
+ memcpy(nvgre_encap_conf.eth_dst, res->eth_dst.addr_bytes,
+ ETHER_ADDR_LEN);
+}
+
+cmdline_parse_inst_t cmd_set_nvgre = {
+ .f = cmd_set_nvgre_parsed,
+ .data = NULL,
+ .help_str = "set nvgre ipv4|ipv6"
+ " ",
+ .tokens = {
+ (void *)&cmd_set_nvgre_set,
+ (void *)&cmd_set_nvgre_nvgre,
+ (void *)&cmd_set_nvgre_ip_version,
+ (void *)&cmd_set_nvgre_tni,
+ (void *)&cmd_set_nvgre_ip_src,
+ (void *)&cmd_set_nvgre_ip_dst,
+ (void *)&cmd_set_nvgre_eth_src,
+ (void *)&cmd_set_nvgre_eth_dst,
+ NULL,
+ },
+};
+
/* Strict link priority scheduling mode setting */
static void
cmd_strict_link_prio_parsed(
@@ -17552,6 +17630,7 @@ cmdline_parse_ctx_t main_ctx[] = {
(cmdline_
Re: [dpdk-dev] [PATCH v2 2/2] doc/guides: updated testpmd app user guide for vxlan/nvgre encap/decap
Hi Ferruh, On 14/06/2018 18:19, Ferruh Yigit wrote: On 6/14/2018 6:14 PM, Ferruh Yigit wrote: On 5/14/2018 4:42 PM, Mohammad Abdul Awal wrote: On 14/05/2018 11:35, Iremonger, Bernard wrote: Hi Awal, -Original Message- From: Awal, Mohammad Abdul Sent: Friday, May 11, 2018 6:14 PM To: dev@dpdk.org; Iremonger, Bernard ; adrien.mazarg...@6wind.com Subject: [PATCH v2 2/2] doc/guides: updated testpmd app user guide for vxlan/nvgre encap/decap Updated the testpmd user guide documentation with how to used new action Typo, "used" in line above should be "use". Will fix. Hi Awal, If this is the only change I can fix this while merging. Are you planning a new version of the set? I just recognized that Nelio has a set that replaces this one: https://dpdk.org/dev/patchwork/patch/41144/ https://dpdk.org/dev/patchwork/patch/41145/ Are you OK to continue with above patches and mark this set as superseded? I am OK marking my patches to be superseded by Neilo's patchset.
[dpdk-dev] [PATCH 1/2] doc: add port representor update in release notes
Signed-off-by: Mohammad Abdul Awal --- doc/guides/rel_notes/release_18_05.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst index e8d74f507..511d51908 100644 --- a/doc/guides/rel_notes/release_18_05.rst +++ b/doc/guides/rel_notes/release_18_05.rst @@ -313,6 +313,16 @@ New Features on eth devices (right now only via SW RX/TX callbacks). It also adds dependency on libelf. +* **Added support for port representors.** + + The DPDK port representors (also known as "VF representors" in the specific + context of VFs), which are to DPDK what the Ethernet switch device driver + model (**switchdev**) is to Linux, and which can be thought as a software + "patch panel" front-end for applications. DPDK port representors are + implemented as additional virtual Ethernet device (**ethdev**) instances, + spawned on an as needed basis through configuration parameters passed to the + driver of the underlying device using devargs. + API Changes --- -- 2.17.0
[dpdk-dev] [PATCH 2/2] doc: add vxlan and nvgre tunnel update in release notes
Signed-off-by: Mohammad Abdul Awal --- doc/guides/rel_notes/release_18_05.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst index 511d51908..37d102572 100644 --- a/doc/guides/rel_notes/release_18_05.rst +++ b/doc/guides/rel_notes/release_18_05.rst @@ -323,6 +323,15 @@ New Features spawned on an as needed basis through configuration parameters passed to the driver of the underlying device using devargs. +* **Added support for VXLAN and NVGRE tunnel endpoint.** + + New actions types have been added to support encapsulation and decapsulation + operations for a tunnel endpoint. The new action types are + RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP, RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP, + RTE_FLOW_ACTION_TYPE_JUMP. New item type RTE_FLOW_ACTION_TYPE_MARK has been + added to match a flow against a previously marked flow. It also introduced shared + counter to flow API to counte for a group of flows. + API Changes --- @@ -457,6 +466,14 @@ API Changes redirect matching traffic to a specific physical port. * PORT_ID pattern item and actions were added to match and target DPDK port IDs at a higher level than PHY_PORT. + * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP action items were added to support +tunnel encapsulation operation for VXLAN and NVGRE type tunnel endpoint. + * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP action items were added to support +tunnel decapsulation operation for VXLAN and NVGRE type tunnel endpoint. + * RTE_FLOW_ACTION_TYPE_JUMP action item was added to support a matched flow +to be redirected to the specific group. + * RTE_FLOW_ACTION_TYPE_MARK item type has been added to match a flow against +a previously marked flow. * ethdev: change flow APIs regarding count action: * ``rte_flow_create()`` API count action now requires the ``struct rte_flow_action_count``. -- 2.17.0
[dpdk-dev] [PATCH 2/2] doc: add vxlan and nvgre tunnel update in release notes
Change-Id: Ibcb8d2343db7f3ac8346dd2ac73ff93e026e0431 Signed-off-by: Mohammad Abdul Awal --- doc/guides/rel_notes/release_18_05.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst index 511d51908..37d102572 100644 --- a/doc/guides/rel_notes/release_18_05.rst +++ b/doc/guides/rel_notes/release_18_05.rst @@ -323,6 +323,15 @@ New Features spawned on an as needed basis through configuration parameters passed to the driver of the underlying device using devargs. +* **Added support for VXLAN and NVGRE tunnel endpoint.** + + New actions types have been added to support encapsulation and decapsulation + operations for a tunnel endpoint. The new action types are + RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP, RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP, + RTE_FLOW_ACTION_TYPE_JUMP. New item type RTE_FLOW_ACTION_TYPE_MARK has been + added to match a flow against a previously marked flow. It also introduced shared + counter to flow API to counte for a group of flows. + API Changes --- @@ -457,6 +466,14 @@ API Changes redirect matching traffic to a specific physical port. * PORT_ID pattern item and actions were added to match and target DPDK port IDs at a higher level than PHY_PORT. + * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_ENCAP action items were added to support +tunnel encapsulation operation for VXLAN and NVGRE type tunnel endpoint. + * RTE_FLOW_ACTION_TYPE_[VXLAN/NVGRE]_DECAP action items were added to support +tunnel decapsulation operation for VXLAN and NVGRE type tunnel endpoint. + * RTE_FLOW_ACTION_TYPE_JUMP action item was added to support a matched flow +to be redirected to the specific group. + * RTE_FLOW_ACTION_TYPE_MARK item type has been added to match a flow against +a previously marked flow. * ethdev: change flow APIs regarding count action: * ``rte_flow_create()`` API count action now requires the ``struct rte_flow_action_count``. -- 2.17.0
[dpdk-dev] [PATCH 1/2] doc: add port representor update in release notes
Change-Id: I21f59c0e540577970c2f3bb8fcd6536fb1ccaefb Signed-off-by: Mohammad Abdul Awal --- doc/guides/rel_notes/release_18_05.rst | 10 ++ 1 file changed, 10 insertions(+) diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst index e8d74f507..511d51908 100644 --- a/doc/guides/rel_notes/release_18_05.rst +++ b/doc/guides/rel_notes/release_18_05.rst @@ -313,6 +313,16 @@ New Features on eth devices (right now only via SW RX/TX callbacks). It also adds dependency on libelf. +* **Added support for port representors.** + + The DPDK port representors (also known as "VF representors" in the specific + context of VFs), which are to DPDK what the Ethernet switch device driver + model (**switchdev**) is to Linux, and which can be thought as a software + "patch panel" front-end for applications. DPDK port representors are + implemented as additional virtual Ethernet device (**ethdev**) instances, + spawned on an as needed basis through configuration parameters passed to the + driver of the underlying device using devargs. + API Changes --- -- 2.17.0
Re: [dpdk-dev] [PATCH v2 2/2] doc/guides: updated testpmd app user guide for vxlan/nvgre encap/decap
On 14/05/2018 11:35, Iremonger, Bernard wrote:
Hi Awal,
-Original Message-
From: Awal, Mohammad Abdul
Sent: Friday, May 11, 2018 6:14 PM
To: dev@dpdk.org; Iremonger, Bernard ;
adrien.mazarg...@6wind.com
Subject: [PATCH v2 2/2] doc/guides: updated testpmd app user guide for
vxlan/nvgre encap/decap
Updated the testpmd user guide documentation with how to used new action
Typo, "used" in line above should be "use".
Will fix.
types RTE_FLOW_ACTION_VXLAN_ENCAP, RTE_FLOW_ACTION_VXLAN_DECAP,
RTE_FLOW_ACTION_NVGRE_ENCAP, RTE_FLOW_ACTION_NVGRE_DECAP
capabilities.
Signed-off-by: Mohammad Abdul Awal
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 50
+
1 file changed, 50 insertions(+)
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 542c217..6ee3ff3 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3559,6 +3559,56 @@ This section lists supported actions and their
attributes, if any.
- ``ethertype``: Ethertype.
+- ``vxlan_encap``: encapsulate the inner flow with pattern of headers
+ according to RFC7348.
+
+ - ``eth_dst {MAC-48}``: outer ether destination.
+
+ - ``eth_src {MAC-48}``: outer ether source.
+
+ - ``eth_type {unsigned}``: outer ether type.
+
+ - ``vlan_tci {unsigned}``: outer vlan tci.
+
+ - ``ipv4_dst {ipv4 address}``: outer ipv4 destination.
+
+ - ``ipv4_src {ipv4 address}``: outer ipv4 source.
+
+ - ``ipv4_proto {unsigned}``: outer ipv4 proto.
+
+ - ``udp_dst {unsigned}``: outer udp destination.
+
+ - ``udp_src {unsigned}``: outer udp source.
+
+ - ``vxlan_vni {unsigned}``: outer vxlan vni.
+
+ - ``end``: outer vxlan header pattern end.
+
+- ``vxlan_decap``: decapsulate the vxlan tunnel flow according to RFC7348.
+
+- ``nvgre_encap``: encapsulate the inner flow with pattern of headers
+ according to RFC7637.
+
+ - ``eth_dst {MAC-48}``: outer ether destination.
+
+ - ``eth_src {MAC-48}``: outer ether source.
+
+ - ``eth_type {unsigned}``: outer ether type.
+
+ - ``vlan_tci {unsigned}``: outer vlan tci.
+
+ - ``ipv4_dst {ipv4 address}``: outer ipv4 destination.
+
+ - ``ipv4_src {ipv4 address}``: outer ipv4 source.
+
+ - ``ipv4_proto {unsigned}``: outer ipv4 proto.
+
+ - ``nvgre_vsni {unsigned}``: outer nvgre vsni.
+
+ - ``end``: outer nvgre header pattern end.
+
+- ``nvgre_decap``: decapsulate the nvgre tunnel flow according to RFC7637.
+
Destroying flow rules
~
I see that section 4.14.1 has been updated to document the syntax of the encap
and decap actions, which look fine.
However my comment on the v1 patch about adding some sample encap and decap
rules has not been addressed.
My understanding is, that it is a two stage process where the tunnel endpoint
flow is created first and the encapsulated flow is then created, this is not
obvious from the syntax description section.
I think it would be useful to add some sample flows after section 4.12.8
The two stage process may be a PMD implementation specific. Since we do
not have any underlying hw yet to exploit the tunnel API, adding a
specific example will make user more confused. Using the above
description will enable a user to create a flow to take into account
nvgre/vxlan encap decap actions.
--
2.7.4
[dpdk-dev] [PATCH v2 2/2] doc/guides: updated testpmd app user guide for vxlan/nvgre encap/decap
Updated the testpmd user guide documentation with how to used new action
types RTE_FLOW_ACTION_VXLAN_ENCAP, RTE_FLOW_ACTION_VXLAN_DECAP,
RTE_FLOW_ACTION_NVGRE_ENCAP, RTE_FLOW_ACTION_NVGRE_DECAP capabilities.
Signed-off-by: Mohammad Abdul Awal
---
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 50 +
1 file changed, 50 insertions(+)
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index 542c217..6ee3ff3 100644
--- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst
+++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
@@ -3559,6 +3559,56 @@ This section lists supported actions and their
attributes, if any.
- ``ethertype``: Ethertype.
+- ``vxlan_encap``: encapsulate the inner flow with pattern of headers
+ according to RFC7348.
+
+ - ``eth_dst {MAC-48}``: outer ether destination.
+
+ - ``eth_src {MAC-48}``: outer ether source.
+
+ - ``eth_type {unsigned}``: outer ether type.
+
+ - ``vlan_tci {unsigned}``: outer vlan tci.
+
+ - ``ipv4_dst {ipv4 address}``: outer ipv4 destination.
+
+ - ``ipv4_src {ipv4 address}``: outer ipv4 source.
+
+ - ``ipv4_proto {unsigned}``: outer ipv4 proto.
+
+ - ``udp_dst {unsigned}``: outer udp destination.
+
+ - ``udp_src {unsigned}``: outer udp source.
+
+ - ``vxlan_vni {unsigned}``: outer vxlan vni.
+
+ - ``end``: outer vxlan header pattern end.
+
+- ``vxlan_decap``: decapsulate the vxlan tunnel flow according to RFC7348.
+
+- ``nvgre_encap``: encapsulate the inner flow with pattern of headers
+ according to RFC7637.
+
+ - ``eth_dst {MAC-48}``: outer ether destination.
+
+ - ``eth_src {MAC-48}``: outer ether source.
+
+ - ``eth_type {unsigned}``: outer ether type.
+
+ - ``vlan_tci {unsigned}``: outer vlan tci.
+
+ - ``ipv4_dst {ipv4 address}``: outer ipv4 destination.
+
+ - ``ipv4_src {ipv4 address}``: outer ipv4 source.
+
+ - ``ipv4_proto {unsigned}``: outer ipv4 proto.
+
+ - ``nvgre_vsni {unsigned}``: outer nvgre vsni.
+
+ - ``end``: outer nvgre header pattern end.
+
+- ``nvgre_decap``: decapsulate the nvgre tunnel flow according to RFC7637.
+
Destroying flow rules
~
--
2.7.4
[dpdk-dev] [PATCH v2 1/2] app/testpmd: enabled vxlan and nvgre encap/decap support for rte_flow
We have enabled testpmd application with ability to create a flow with
vxlan/nvgre tunnel types and with encapsulation/decapsulation
functionalities.
Signed-off-by: Mohammad Abdul Awal
---
app/test-pmd/cmdline_flow.c | 937
1 file changed, 937 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5754e78..5ffc127 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -237,6 +237,48 @@ enum index {
ACTION_OF_POP_MPLS_ETHERTYPE,
ACTION_OF_PUSH_MPLS,
ACTION_OF_PUSH_MPLS_ETHERTYPE,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_DST_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE_VALUE,
+ ACTION_VXLAN_ENCAP_VLAN_TCI,
+ ACTION_VXLAN_ENCAP_VLAN_TCI_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_IPV4_DST_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_SRC,
+ ACTION_VXLAN_ENCAP_IPV4_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_SRC,
+ ACTION_VXLAN_ENCAP_UDP_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_DST,
+ ACTION_VXLAN_ENCAP_UDP_DST_VALUE,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI_VALUE,
+ ACTION_VXLAN_ENCAP_END,
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_ENCAP_ETH_DST,
+ ACTION_NVGRE_ENCAP_ETH_DST_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_SRC,
+ ACTION_NVGRE_ENCAP_ETH_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE_VALUE,
+ ACTION_NVGRE_ENCAP_VLAN_TCI,
+ ACTION_NVGRE_ENCAP_VLAN_TCI_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_DST,
+ ACTION_NVGRE_ENCAP_IPV4_DST_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_SRC,
+ ACTION_NVGRE_ENCAP_IPV4_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI_VALUE,
+ ACTION_NVGRE_ENCAP_END,
+ ACTION_NVGRE_DECAP,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -256,6 +298,30 @@ struct action_rss_data {
uint16_t queue[ACTION_RSS_QUEUE_NUM];
};
+#define ACTION_VXLAN_ENCAP_MAX_PATTERN 5
+#define ACTION_NVGRE_ENCAP_MAX_PATTERN 4
+
+struct action_vxlan_encap_data {
+ struct rte_flow_action_vxlan_encap conf;
+ struct rte_flow_item pattern[ACTION_VXLAN_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_vlan vlan;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_udp udp;
+ struct rte_flow_item_vxlan vxlan;
+ uint32_t hdr_flags;
+};
+
+struct action_nvgre_encap_data {
+ struct rte_flow_action_nvgre_encap conf;
+ struct rte_flow_item pattern[ACTION_NVGRE_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_vlan vlan;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_nvgre nvgre;
+ uint32_t hdr_flags;
+};
+
/** Maximum number of subsequent tokens and arguments on the stack. */
#define CTX_STACK_SIZE 16
@@ -383,6 +449,13 @@ struct token {
.size = (s), \
})
+#define ARGS_ENTRY_ARB_HTON(o, s) \
+ (&(const struct arg){ \
+ .hton = 1, \
+ .offset = (o), \
+ .size = (s), \
+ })
+
/** Same as ARGS_ENTRY_ARB() with bounded values. */
#define ARGS_ENTRY_ARB_BOUNDED(o, s, i, a) \
(&(const struct arg){ \
@@ -773,6 +846,10 @@ static const enum index next_action[] = {
ACTION_OF_SET_VLAN_PCP,
ACTION_OF_POP_MPLS,
ACTION_OF_PUSH_MPLS,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_DECAP,
ZERO,
};
@@ -874,6 +951,46 @@ static const enum index action_jump[] = {
ZERO,
};
+static const enum index action_vxlan_encap[] = {
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_VLAN_TCI,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_IPV4_SRC,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO,
+ ACTION_VXLAN_ENCAP_UDP_DST,
+ ACTION_VXLAN_ENCAP_UDP_SRC,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI,
+ ACTION_VXLAN_ENCAP_END,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_vxlan_decap[] = {
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_nvgre_encap[] = {
+ ACTION_NVGRE_ENCAP_ETH_DST,
+ ACTION_NVGRE_ENCAP_ETH_SRC,
+ ACTION_NVGRE_ENCAP_ETH_TYPE,
+ ACTION_NVGRE_ENCAP_VLAN_TCI,
+ ACTION_NVGRE_ENCAP_IPV4_DST,
+ ACTION_NVGRE_ENCAP_IPV4_SRC,
+ ACTION_NVGRE_ENCAP_IP
[dpdk-dev] [PATCH v2 0/2] Added vxlan/nvgre encap/decap support to testpmd
Changes in v2: * Added documentation in testpmd user guide. * Added vlan header for vxlan/nvgre encap. * Fixed other comments. In this patch set we have enabled testpmd application with ability to create a flow with vxlan/nvgre tunnel types and with encapsulation/decapsulation functionalities. We have also updated the testpmd user guide documentation with how to used new action types RTE_FLOW_ACTION_VXLAN_ENCAP, RTE_FLOW_ACTION_VXLAN_DECAP, RTE_FLOW_ACTION_NVGRE_ENCAP, RTE_FLOW_ACTION_NVGRE_DECAP capabilities. Mohammad Abdul Awal (2): app/testpmd: enabled vxlan and nvgre encap/decap support for rte_flow doc/guides: updated testpmd app user guide for vxlan/nvgre encap/decap app/test-pmd/cmdline_flow.c | 937 doc/guides/testpmd_app_ug/testpmd_funcs.rst | 50 ++ 2 files changed, 987 insertions(+) -- 2.7.4
Re: [dpdk-dev] [PATCH v2 2/2] net/ixgbe: fix missing Port Representor data-path
On 11/05/2018 13:28, Remy Horton wrote:
This patch adds Rx and Tx burst functions to the ixgbe
Port Representors, so that the implementation within
ixgbe PMD can be tested using applications such as
testpmd which require data-path functionality.
Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")
Signed-off-by: Remy Horton
---
drivers/net/ixgbe/ixgbe_vf_representor.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c
b/drivers/net/ixgbe/ixgbe_vf_representor.c
index 8f8af49..db516d9 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -153,6 +153,20 @@ struct eth_dev_ops ixgbe_vf_representor_dev_ops = {
.mac_addr_set = ixgbe_vf_representor_mac_addr_set,
};
+static uint16_t
+ixgbe_vf_representor_rx_burst(__rte_unused void *rx_queue,
+ __rte_unused struct rte_mbuf **rx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
+static uint16_t
+ixgbe_vf_representor_tx_burst(__rte_unused void *tx_queue,
+ __rte_unused struct rte_mbuf **tx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
int
ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
{
@@ -182,9 +196,11 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void
*init_params)
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
- /* No data-path so no RX/TX functions */
- ethdev->rx_pkt_burst = NULL;
- ethdev->tx_pkt_burst = NULL;
+ /* No data-path, but need stub Rx/Tx functions to avoid crash
+* when testing with the likes of testpmd.
+*/
+ ethdev->rx_pkt_burst = ixgbe_vf_representor_rx_burst;
+ ethdev->tx_pkt_burst = ixgbe_vf_representor_tx_burst;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v2 1/2] net/i40e: fix missing Port Representor data-path
On 11/05/2018 13:28, Remy Horton wrote:
This patch adds Rx and Tx burst functions to the i40e Port
Representors, so that the implementation within this PMD
can be tested using applications such as testpmd which
require data-path functionality.
Fixes: e0cb96204b71 ("net/i40e: add support for representor ports")
Signed-off-by: Remy Horton
---
drivers/net/i40e/i40e_vf_representor.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_vf_representor.c
b/drivers/net/i40e/i40e_vf_representor.c
index 96b3787..6026ec9 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -337,6 +337,20 @@ struct eth_dev_ops i40e_representor_dev_ops = {
};
+static uint16_t
+i40e_vf_representor_rx_burst(__rte_unused void *rx_queue,
+ __rte_unused struct rte_mbuf **rx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
+static uint16_t
+i40e_vf_representor_tx_burst(__rte_unused void *tx_queue,
+ __rte_unused struct rte_mbuf **tx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
int
i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
{
@@ -365,9 +379,11 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void
*init_params)
/* Set representor device ops */
ethdev->dev_ops = &i40e_representor_dev_ops;
- /* No data-path so no RX/TX functions */
- ethdev->rx_pkt_burst = NULL;
- ethdev->tx_pkt_burst = NULL;
+ /* No data-path, but need stub Rx/Tx functions to avoid crash
+* when testing with the likes of testpmd.
+*/
+ ethdev->rx_pkt_burst = i40e_vf_representor_rx_burst;
+ ethdev->tx_pkt_burst = i40e_vf_representor_tx_burst;
vf = &pf->vfs[representor->vf_id];
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [DPDK] net/ixgbe: fix missing Port Representor data-path callbacks
On 09/05/2018 16:00, Remy Horton wrote:
This patch adds Rx and Tx burst functions to the ixgbe
Port Representors, so that the implementation within
ixgbe PMD can be tested using applications such as
testpmd which require data-path functionality.
Fixes: cf80ba6e2038 ("net/ixgbe: add support for representor ports")
Signed-off-by: Remy Horton
---
drivers/net/ixgbe/ixgbe_vf_representor.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_vf_representor.c
b/drivers/net/ixgbe/ixgbe_vf_representor.c
index 8f8af49..21c44d1 100644
--- a/drivers/net/ixgbe/ixgbe_vf_representor.c
+++ b/drivers/net/ixgbe/ixgbe_vf_representor.c
@@ -153,6 +153,25 @@ struct eth_dev_ops ixgbe_vf_representor_dev_ops = {
.mac_addr_set = ixgbe_vf_representor_mac_addr_set,
};
+static uint16_t
+ixgbe_vf_representor_rx_burst(__rte_unused void *rx_queue,
+ __rte_unused struct rte_mbuf **rx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
+static uint16_t
+ixgbe_vf_representor_tx_burst(__rte_unused void *tx_queue,
+ struct rte_mbuf **tx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t idx_pkt;
+
+ for (idx_pkt = 0; idx_pkt < nb_pkts; idx_pkt++)
+ rte_pktmbuf_free(tx_pkts[idx_pkt]);
We should not free them in the driver silently whereas the application
will think that it has been sent successfully.
Please use the same rule for rx_burst, and return 0.
+ return nb_pkts;
+}
+
int
ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
{
@@ -182,9 +201,11 @@ ixgbe_vf_representor_init(struct rte_eth_dev *ethdev, void
*init_params)
/* Set representor device ops */
ethdev->dev_ops = &ixgbe_vf_representor_dev_ops;
- /* No data-path so no RX/TX functions */
- ethdev->rx_pkt_burst = NULL;
- ethdev->tx_pkt_burst = NULL;
+ /* No data-path, but need stub Rx/Tx functions to avoid crash
+* when testing with the likes of testpmd.
+*/
+ ethdev->rx_pkt_burst = ixgbe_vf_representor_rx_burst;
+ ethdev->tx_pkt_burst = ixgbe_vf_representor_tx_burst;
/* Setting the number queues allocated to the VF */
ethdev->data->nb_rx_queues = IXGBE_VF_MAX_RX_QUEUES;
Re: [dpdk-dev] [PATCH] net/i40e: fix missing Port Representor data-path callbacks
On 09/05/2018 16:00, Remy Horton wrote:
This patch adds Rx and Tx burst functions to the i40e Port
Representors, so that the implementation within this PMD
can be tested using applications such as testpmd which
require data-path functionality.
Fixes: e0cb96204b71 ("net/i40e: add support for representor ports")
Signed-off-by: Remy Horton
---
drivers/net/i40e/i40e_vf_representor.c | 27 ---
1 file changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/net/i40e/i40e_vf_representor.c
b/drivers/net/i40e/i40e_vf_representor.c
index 96b3787..e205019 100644
--- a/drivers/net/i40e/i40e_vf_representor.c
+++ b/drivers/net/i40e/i40e_vf_representor.c
@@ -337,6 +337,25 @@ struct eth_dev_ops i40e_representor_dev_ops = {
};
+static uint16_t
+i40e_vf_representor_rx_burst(__rte_unused void *rx_queue,
+ __rte_unused struct rte_mbuf **rx_pkts, __rte_unused uint16_t nb_pkts)
+{
+ return 0;
+}
+
+static uint16_t
+i40e_vf_representor_tx_burst(__rte_unused void *tx_queue,
+ struct rte_mbuf **tx_pkts,
+ uint16_t nb_pkts)
+{
+ uint16_t idx_pkt;
+
+ for (idx_pkt = 0; idx_pkt < nb_pkts; idx_pkt++)
+ rte_pktmbuf_free(tx_pkts[idx_pkt]);
We should not free them in the driver silently whereas the application
will think that it has been sent successfully.
Please use the same rule for rx_burst, and return 0.
+ return nb_pkts;
+}
+
int
i40e_vf_representor_init(struct rte_eth_dev *ethdev, void *init_params)
{
@@ -365,9 +384,11 @@ i40e_vf_representor_init(struct rte_eth_dev *ethdev, void
*init_params)
/* Set representor device ops */
ethdev->dev_ops = &i40e_representor_dev_ops;
- /* No data-path so no RX/TX functions */
- ethdev->rx_pkt_burst = NULL;
- ethdev->tx_pkt_burst = NULL;
+ /* No data-path, but need stub Rx/Tx functions to avoid crash
+* when testing with the likes of testpmd.
+*/
+ ethdev->rx_pkt_burst = i40e_vf_representor_rx_burst;
+ ethdev->tx_pkt_burst = i40e_vf_representor_tx_burst;
vf = &pf->vfs[representor->vf_id];
Re: [dpdk-dev] [PATCH] app/testpmd: enabled vxlan and nvgre encap/decap support for rte_flow
Hi Bernard,
On 10/05/2018 13:47, Iremonger, Bernard wrote:
Hi Awal,
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mohammad Abdul
Awal
Sent: Wednesday, May 9, 2018 5:57 PM
To: dev@dpdk.org
Cc: Awal, Mohammad Abdul
Subject: [dpdk-dev] [PATCH] app/testpmd: enabled vxlan and nvgre encap/decap
support for rte_flow
The commit message should not be empty, it should contain a description of the
changes
I will add some message here.
Signed-off-by: Mohammad Abdul Awal
---
app/test-pmd/cmdline_flow.c | 872
1 file changed, 872 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c index
5754e78..7d80f2a 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -237,6 +237,44 @@ enum index {
ACTION_OF_POP_MPLS_ETHERTYPE,
ACTION_OF_PUSH_MPLS,
ACTION_OF_PUSH_MPLS_ETHERTYPE,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_DST_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_IPV4_DST_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_SRC,
+ ACTION_VXLAN_ENCAP_IPV4_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_SRC,
+ ACTION_VXLAN_ENCAP_UDP_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_DST,
+ ACTION_VXLAN_ENCAP_UDP_DST_VALUE,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI_VALUE,
+ ACTION_VXLAN_ENCAP_END,
Is ACTION_VXLAN_ENCAP_END necessary, could ACTION_END be used instead?
Actually, ACTION_VXLAN_ENCAP_END is different than ACTION_END.
ACTION_END creates the RTE_FLOW_ACTION_TYPE_END.
On the other hand, ACTION_VXLAN_ENCAP_END created RTE_FLOW_ITEM_TYPE_END
at the end pf patterns in the encap definition which is pattern of items
end by item_end.
So, to treat the two situations separately we need
ACTION_VXLAN_ENCAP_END, unless there is a clever way present.
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_ENCAP_ETH_DST,
+ ACTION_NVGRE_ENCAP_ETH_DST_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_SRC,
+ ACTION_NVGRE_ENCAP_ETH_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_DST,
+ ACTION_NVGRE_ENCAP_IPV4_DST_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_SRC,
+ ACTION_NVGRE_ENCAP_IPV4_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI_VALUE,
+ ACTION_NVGRE_ENCAP_END,
Is ACTION_NVGRE_ENCAP_END necessary, could ACTION_END be used instead?
Please see my related comment above.
+ ACTION_NVGRE_DECAP,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */ @@ -256,6
+294,28 @@ struct action_rss_data {
uint16_t queue[ACTION_RSS_QUEUE_NUM];
};
+#define ACTION_VXLAN_ENCAP_MAX_PATTERN 5 #define
+ACTION_NVGRE_ENCAP_MAX_PATTERN 4
+
+struct action_vxlan_encap_data {
+ struct rte_flow_action_vxlan_encap conf;
+ struct rte_flow_item pattern[ACTION_VXLAN_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_udp udp;
+ struct rte_flow_item_vxlan vxlan;
+ uint32_t hdr_flags;
+};
+
+struct action_nvgre_encap_data {
+ struct rte_flow_action_nvgre_encap conf;
+ struct rte_flow_item pattern[ACTION_NVGRE_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_nvgre nvgre;
+ uint32_t hdr_flags;
+};
+
/** Maximum number of subsequent tokens and arguments on the stack. */
#define CTX_STACK_SIZE 16
@@ -383,6 +443,13 @@ struct token {
.size = (s), \
})
+#define ARGS_ENTRY_ARB_HTON(o, s) \
+ (&(const struct arg){ \
+ .hton = 1, \
+ .offset = (o), \
+ .size = (s), \
+ })
+
/** Same as ARGS_ENTRY_ARB() with bounded values. */ #define
ARGS_ENTRY_ARB_BOUNDED(o, s, i, a) \
(&(const struct arg){ \
@@ -773,6 +840,10 @@ static const enum index next_action[] = {
ACTION_OF_SET_VLAN_PCP,
ACTION_OF_POP_MPLS,
ACTION_OF_PUSH_MPLS,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_DECAP,
ZERO,
};
@@ -874,6 +945,44 @@ static const enum index action_jump[] = {
ZERO,
};
+static const enum index action_vxlan_encap[] = {
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_
[dpdk-dev] [PATCH] app/testpmd: enabled vxlan and nvgre encap/decap support for rte_flow
Signed-off-by: Mohammad Abdul Awal
---
app/test-pmd/cmdline_flow.c | 872
1 file changed, 872 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index 5754e78..7d80f2a 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -237,6 +237,44 @@ enum index {
ACTION_OF_POP_MPLS_ETHERTYPE,
ACTION_OF_PUSH_MPLS,
ACTION_OF_PUSH_MPLS_ETHERTYPE,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_DST_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_ETH_TYPE_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_IPV4_DST_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_SRC,
+ ACTION_VXLAN_ENCAP_IPV4_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_SRC,
+ ACTION_VXLAN_ENCAP_UDP_SRC_VALUE,
+ ACTION_VXLAN_ENCAP_UDP_DST,
+ ACTION_VXLAN_ENCAP_UDP_DST_VALUE,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI_VALUE,
+ ACTION_VXLAN_ENCAP_END,
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_ENCAP_ETH_DST,
+ ACTION_NVGRE_ENCAP_ETH_DST_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_SRC,
+ ACTION_NVGRE_ENCAP_ETH_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE,
+ ACTION_NVGRE_ENCAP_ETH_TYPE_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_DST,
+ ACTION_NVGRE_ENCAP_IPV4_DST_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_SRC,
+ ACTION_NVGRE_ENCAP_IPV4_SRC_VALUE,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO_VALUE,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI_VALUE,
+ ACTION_NVGRE_ENCAP_END,
+ ACTION_NVGRE_DECAP,
};
/** Maximum size for pattern in struct rte_flow_item_raw. */
@@ -256,6 +294,28 @@ struct action_rss_data {
uint16_t queue[ACTION_RSS_QUEUE_NUM];
};
+#define ACTION_VXLAN_ENCAP_MAX_PATTERN 5
+#define ACTION_NVGRE_ENCAP_MAX_PATTERN 4
+
+struct action_vxlan_encap_data {
+ struct rte_flow_action_vxlan_encap conf;
+ struct rte_flow_item pattern[ACTION_VXLAN_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_udp udp;
+ struct rte_flow_item_vxlan vxlan;
+ uint32_t hdr_flags;
+};
+
+struct action_nvgre_encap_data {
+ struct rte_flow_action_nvgre_encap conf;
+ struct rte_flow_item pattern[ACTION_NVGRE_ENCAP_MAX_PATTERN];
+ struct rte_flow_item_eth eth;
+ struct rte_flow_item_ipv4 ipv4;
+ struct rte_flow_item_nvgre nvgre;
+ uint32_t hdr_flags;
+};
+
/** Maximum number of subsequent tokens and arguments on the stack. */
#define CTX_STACK_SIZE 16
@@ -383,6 +443,13 @@ struct token {
.size = (s), \
})
+#define ARGS_ENTRY_ARB_HTON(o, s) \
+ (&(const struct arg){ \
+ .hton = 1, \
+ .offset = (o), \
+ .size = (s), \
+ })
+
/** Same as ARGS_ENTRY_ARB() with bounded values. */
#define ARGS_ENTRY_ARB_BOUNDED(o, s, i, a) \
(&(const struct arg){ \
@@ -773,6 +840,10 @@ static const enum index next_action[] = {
ACTION_OF_SET_VLAN_PCP,
ACTION_OF_POP_MPLS,
ACTION_OF_PUSH_MPLS,
+ ACTION_VXLAN_ENCAP,
+ ACTION_VXLAN_DECAP,
+ ACTION_NVGRE_ENCAP,
+ ACTION_NVGRE_DECAP,
ZERO,
};
@@ -874,6 +945,44 @@ static const enum index action_jump[] = {
ZERO,
};
+static const enum index action_vxlan_encap[] = {
+ ACTION_VXLAN_ENCAP_ETH_DST,
+ ACTION_VXLAN_ENCAP_ETH_SRC,
+ ACTION_VXLAN_ENCAP_ETH_TYPE,
+ ACTION_VXLAN_ENCAP_IPV4_DST,
+ ACTION_VXLAN_ENCAP_IPV4_SRC,
+ ACTION_VXLAN_ENCAP_IPV4_PROTO,
+ ACTION_VXLAN_ENCAP_UDP_DST,
+ ACTION_VXLAN_ENCAP_UDP_SRC,
+ ACTION_VXLAN_ENCAP_VXLAN_VNI,
+ ACTION_VXLAN_ENCAP_END,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_vxlan_decap[] = {
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_nvgre_encap[] = {
+ ACTION_NVGRE_ENCAP_ETH_DST,
+ ACTION_NVGRE_ENCAP_ETH_SRC,
+ ACTION_NVGRE_ENCAP_ETH_TYPE,
+ ACTION_NVGRE_ENCAP_IPV4_DST,
+ ACTION_NVGRE_ENCAP_IPV4_SRC,
+ ACTION_NVGRE_ENCAP_IPV4_PROTO,
+ ACTION_NVGRE_ENCAP_NVGRE_VSNI,
+ ACTION_NVGRE_ENCAP_END,
+ ACTION_NEXT,
+ ZERO,
+};
+
+static const enum index action_nvgre_decap[] = {
+ ACTION_NEXT,
+ ZERO,
+};
+
static int parse_init(struct context *, const struct token *,
const char *, unsigned int,
void *, unsigned int);
@@ -896,6 +1005,42 @@ static int parse_vc_action_rss_type(struct context *,
const struct token *,
static int parse_vc_action_r
Re: [dpdk-dev] [PATCH v4 15/16] ethdev: add physical port action to flow API
On 16/04/2018 17:22, Adrien Mazarguil wrote:
This patch adds the missing action counterpart to the PHY_PORT pattern
item, that is, the ability to directly inject matching traffic into a
physical port of the underlying device.
It breaks ABI compatibility for the following public functions:
- rte_flow_copy()
- rte_flow_create()
- rte_flow_query()
- rte_flow_validate()
Signed-off-by: Adrien Mazarguil
Acked-by: Andrew Rybchenko
Cc: "Zhang, Qi Z"
Acked-by: Mohammad Abdul Awal
---
app/test-pmd/cmdline_flow.c | 35
app/test-pmd/config.c | 1 +
doc/guides/prog_guide/rte_flow.rst | 20 ++
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 5
lib/librte_ether/rte_flow.c | 1 +
lib/librte_ether/rte_flow.h | 22 +++
6 files changed, 84 insertions(+)
diff --git a/app/test-pmd/cmdline_flow.c b/app/test-pmd/cmdline_flow.c
index f9f937277..356714801 100644
--- a/app/test-pmd/cmdline_flow.c
+++ b/app/test-pmd/cmdline_flow.c
@@ -182,6 +182,9 @@ enum index {
ACTION_VF,
ACTION_VF_ORIGINAL,
ACTION_VF_ID,
+ ACTION_PHY_PORT,
+ ACTION_PHY_PORT_ORIGINAL,
+ ACTION_PHY_PORT_INDEX,
ACTION_METER,
ACTION_METER_ID,
};
@@ -623,6 +626,7 @@ static const enum index next_action[] = {
ACTION_RSS,
ACTION_PF,
ACTION_VF,
+ ACTION_PHY_PORT,
ACTION_METER,
ZERO,
};
@@ -657,6 +661,13 @@ static const enum index action_vf[] = {
ZERO,
};
+static const enum index action_phy_port[] = {
+ ACTION_PHY_PORT_ORIGINAL,
+ ACTION_PHY_PORT_INDEX,
+ ACTION_NEXT,
+ ZERO,
+};
+
static const enum index action_meter[] = {
ACTION_METER_ID,
ACTION_NEXT,
@@ -1714,6 +1725,30 @@ static const struct token token_list[] = {
.args = ARGS(ARGS_ENTRY(struct rte_flow_action_vf, id)),
.call = parse_vc_conf,
},
+ [ACTION_PHY_PORT] = {
+ .name = "phy_port",
+ .help = "direct packets to physical port index",
+ .priv = PRIV_ACTION(PHY_PORT,
+ sizeof(struct rte_flow_action_phy_port)),
+ .next = NEXT(action_phy_port),
+ .call = parse_vc,
+ },
+ [ACTION_PHY_PORT_ORIGINAL] = {
+ .name = "original",
+ .help = "use original port index if possible",
+ .next = NEXT(action_phy_port, NEXT_ENTRY(BOOLEAN)),
+ .args = ARGS(ARGS_ENTRY_BF(struct rte_flow_action_phy_port,
+ original, 1)),
+ .call = parse_vc_conf,
+ },
+ [ACTION_PHY_PORT_INDEX] = {
+ .name = "index",
+ .help = "physical port index",
+ .next = NEXT(action_phy_port, NEXT_ENTRY(UNSIGNED)),
+ .args = ARGS(ARGS_ENTRY(struct rte_flow_action_phy_port,
+ index)),
+ .call = parse_vc_conf,
+ },
[ACTION_METER] = {
.name = "meter",
.help = "meter the directed packets at given id",
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 840320108..2d68f1fb0 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1074,6 +1074,7 @@ static const struct {
MK_FLOW_ACTION(RSS, sizeof(struct rte_flow_action_rss)),
MK_FLOW_ACTION(PF, 0),
MK_FLOW_ACTION(VF, sizeof(struct rte_flow_action_vf)),
+ MK_FLOW_ACTION(PHY_PORT, sizeof(struct rte_flow_action_phy_port)),
MK_FLOW_ACTION(METER, sizeof(struct rte_flow_action_meter)),
};
diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst
index 4e053c24b..a39c1e1b0 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1433,6 +1433,26 @@ See `Item: VF`_.
| ``id`` | VF ID |
+--++
+Action: ``PHY_PORT``
+
+
+Directs matching traffic to a given physical port index of the underlying
+device.
+
+See `Item: PHY_PORT`_.
+
+.. _table_rte_flow_action_phy_port:
+
+.. table:: PHY_PORT
+
+ +--+-+
+ | Field| Value |
+ +==+=+
+ | ``original`` | use original port index if possible |
+ +--+-+
+ | ``index``| physical port index |
+ +--+-+
+
Action: ``METER``
^
diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst
index a2bb
Re: [dpdk-dev] [PATCH v4 2/5] ethdev: introduce new tunnel VXLAN-GPE
On 16/04/2018 23:23, Thomas Monjalon wrote:
13/04/2018 13:02, Xueming Li:
+struct vxlan_gpe_hdr {
+ uint8_t vx_flags; /**< flag (8). */
+ uint8_t reserved[2]; /**< Reserved (16). */
+ uint8_t proto; /**< next-protocol (8). */
+ uint32_t vx_vni; /**< VNI (24) + Reserved (8). */
+} __attribute__((__packed__));
minor nit: the field comments could be aligned
Once addressed the above comment
Acked-by: Mohammad Abdul Awal
Re: [dpdk-dev] [PATCH v3 2/4] ethdev: Add tunnel encap/decap actions
On 06/04/2018 21:26, Adrien Mazarguil wrote: On Fri, Apr 06, 2018 at 01:24:01PM +0100, Declan Doherty wrote: Add new flow action types and associated action data structures to support the encapsulation and decapsulation of the virtual tunnel endpoints. The RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP action will cause the matching flow to be encapsulated in the virtual tunnel endpoint overlay defined in the tunnel_encap action data. The RTE_FLOW_ACTION_TYPE_TUNNEL_DECAP action will cause all virtual tunnel endpoint overlays up to and including the first instance of the flow item type defined in the tunnel_decap action data for the matching flows. Signed-off-by: Declan Doherty This generic approach looks flexible enough to cover the use cases that immediately come to mind (VLAN, VXLAN), its design is sound. However, while I'm aware it's not a concern at this point, it won't be able to deal with stateful tunnel or encapsulation types (e.g. IPsec or TCP) which will require additional meta data or some run-time assistance from the application. Eventually for more complex use cases, dedicated encap/decap actions will have to appear, so the issue I wanted to raise before going further is this: Going generic inevitably trades some of the usability; flat structures dedicated to VXLAN encap/decap with only the needed info to get the job done would likely be easier to implement in PMDs and use in applications. Any number of such actions can be added to rte_flow without ABI impact. If VXLAN is the only use case at this point, my suggestion would be to go with simpler RTE_FLOW_ACTION_TYPE_VXLAN_(ENCAP|DECAP) actions, with fixed L2/L3/L4/L5 header definitions to prepend according to RFC 7348. We can go this way and this will increase the action for more and more tunneling protocols being added. Current proposal is already a generic approach which specifies as a tunnel for all the tunneling protocols. Now we can start with the generic approach, see how it fares and add dedicated encap/decap later as needed. More comments below. --- doc/guides/prog_guide/rte_flow.rst | 77 -- lib/librte_ether/rte_flow.h| 84 -- 2 files changed, 155 insertions(+), 6 deletions(-) diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index fd33d19..106fb93 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -997,9 +997,11 @@ Actions Each possible action is represented by a type. Some have associated configuration structures. Several actions combined in a list can be assigned -to a flow rule. That list is not ordered. +to a flow rule. That list is not ordered, with the exception of actions which +modify the packet itself, these packet modification actions must be specified +in the explicit order in which they are to be executed. -They fall in three categories: +They fall in four categories: - Terminating actions (such as QUEUE, DROP, RSS, PF, VF) that prevent processing matched packets by subsequent flow rules, unless overridden @@ -1008,8 +1010,11 @@ They fall in three categories: - Non-terminating actions (PASSTHRU, DUP) that leave matched packets up for additional processing by subsequent flow rules. +- Non-terminating meta actions that do not affect the fate of packets but result + in modification of the packet itself (SECURITY, TUNNEL_ENCAP, TUNNEL_DECAP). + - Other non-terminating meta actions that do not affect the fate of packets - (END, VOID, MARK, FLAG, COUNT, SECURITY). + (END, VOID, MARK, FLAG, COUNT). The above changes are not necessary anymore [1][2]. [1] "ethdev: clarify flow API pattern items and actions" https://dpdk.org/ml/archives/dev/2018-April/095776.html [2] "ethdev: alter behavior of flow API actions" https://dpdk.org/ml/archives/dev/2018-April/095779.html OK, we can undo some changes here. When several actions are combined in a flow rule, they should all have different types (e.g. dropping a packet twice is not possible). @@ -1486,6 +1491,72 @@ fields in the pattern items. | 1 | END | +---+--+ + Nit: titles in this file are separated by a single empty line. Fixed. +Action: ``TUNNEL_ENCAP`` +^^ + +Performs an encapsulation action by encapsulating the flows matched by the +pattern items according to the network overlay defined in the +``rte_flow_action_tunnel_encap`` pattern items. + +This action modifies the payload of matched flows. The pattern items specified +in the ``rte_flow_action_tunnel_encap`` action structure must defined a valid +set of overlay headers, from the Ethernet header up to the overlay header. The +pattern must be terminated with the RTE_FLOW_ITEM_TYPE_END item type. Regarding the use of a pattern list, if you consider PMDs are already iterating on a list of actions when encountering RTE_FLOW_ACTION_TYPE_TUNNEL_ENCAP, it a
Re: [dpdk-dev] [PATCH v3 1/4] ethdev: add group counter support to rte_flow
Hi Adrien,
On 06/04/2018 21:26, Adrien Mazarguil wrote:
On Fri, Apr 06, 2018 at 01:24:00PM +0100, Declan Doherty wrote:
Add new RTE_FLOW_ACTION_TYPE_GROUP_COUNT action type to enable shared
counters across multiple flows on a single port or across multiple
flows on multiple ports within the same switch domain.
Introduce new API rte_flow_query_group_count to allow querying of group
counters.
Signed-off-by: Declan Doherty
Both features are definitely needed, however I suggest to enhance the
existing action type and query function instead, given the rte_flow ABI
won't be maintained for the 18.05 release [1].
Counters and query support were defined as a kind of PoC in preparation for
future requirements back in DPDK 17.02 and so far few PMDs have implemented
the query callback (mlx5 and failsafe, and the latter isn't really a PMD).
Due to the behavior change of action lists [2], providing an action type as
a query parameter is not specific enough anymore, for instance if a list
contains multiple COUNT, the application should be able to tell which needs
to be queried.
Therefore I suggest to redefine the query function as follows:
int
rte_flow_query(uint16_t port_id,
struct rte_flow *flow,
const struct rte_flow_action *action,
void *data,
struct rte_flow_error *error);
Third argument is an action definition with the same configuration (if any)
as previously defined in the action list originally used to create the flow
rule (not necessarily the same pointer, only the contents matter).
It means two perfectly identical actions can't be distinguished, and that's
how group counters will work.
Instead of adding a new action type to distinguish groups, a configuration
structure is added to the existing RTE_FLOW_ACTION_TYPE_COUNT, with
non-shared counters as a default behavior:
struct rte_flow_action_count {
uint32_t shared:1; /**< Share counter ID with other flow rules. */
uint32_t reserved:31; /**< Reserved, must be zero. */
uint32_t id; /**< Counter ID. */
};
Doing so will impact some existing code in mlx5 and librte_flow_classify,
but that shouldn't be much of an issue.
Keep in mind testpmd and its documentation must be updated as well.
Thoughts?
Please correct me if I am wrong but I think we are talking two different
things here.
If I understood you correctly, you are proposing to pass a list of
actions (instead if a action type) in the third parameter to perform
multiple actions in the same query call. Lets take an example for 100
ingress flows. So, if we want to query the counter for all the flows, we
can get them by a single query providing a list (of size 100) of
action_count in the 3rd param.
On the other hand, we are saying that all the flows are belongs to same
tunnel end-point (we are talking only 1 TEP here), then the PMD will be
responsible to increment the counter of TEP for matching all the flows
(100 flows). So, using one group query by passing one action_count in
3rd param, we can get the count of the TEP.
This case is generic enough for sure for simple flows but may not be
suitable for tunnel cases, as application needs to track the counters
for all the flows, and needs to build the list of action each time the
flows added/deleted.
A few nits below for the sake of commenting.
[1] "Flow API overhaul for switch offloads"
http://dpdk.org/ml/archives/dev/2018-April/095774.html
[2] "ethdev: alter behavior of flow API actions"
http://dpdk.org/ml/archives/dev/2018-April/095779.html
---
doc/guides/prog_guide/rte_flow.rst | 35 +
lib/librte_ether/rte_ethdev_version.map | 8 +
lib/librte_ether/rte_flow.c | 21 +
lib/librte_ether/rte_flow.h | 56 -
lib/librte_ether/rte_flow_driver.h | 6
5 files changed, 125 insertions(+), 1 deletion(-)
diff --git a/doc/guides/prog_guide/rte_flow.rst
b/doc/guides/prog_guide/rte_flow.rst
index 961943d..fd33d19 100644
--- a/doc/guides/prog_guide/rte_flow.rst
+++ b/doc/guides/prog_guide/rte_flow.rst
@@ -1698,6 +1698,41 @@ Return values:
- 0 on success, a negative errno value otherwise and ``rte_errno`` is set.
+
Unnecessary empty line.
I will take into account all the comments.
Regards,
Awal.
+Group Count Query
+~
+
+Query group counter which can be associated with multiple flows on a specified
+port.
+
+This function allows retrieving of group counters. A group counter is a
+counter which can be shared among multiple flows on a single port or among
+multiple flows on multiple ports within the same switch domain. Data is
+gathered by special actions which must be present in the flow rule
+definition.
+
+.. code-block:: c
+
+ int
+ rte_flow_query_group_count(uint16_t port_id,
+ uint32_t group_counter_id,
+ struct rte_flow_quer
Re: [dpdk-dev] [PATCH v2 4/4] ethdev: Add metadata flow and action items support
On 06/04/2018 16:57, Thomas Monjalon wrote:
06/04/2018 15:47, Mohammad Abdul Awal:
On 05/04/2018 17:49, Thomas Monjalon wrote:
05/04/2018 15:51, Declan Doherty:
+struct rte_flow_item_metadata {
+ uint32_t id;/**< field identifier */
+ uint32_t size; /**< field size */
+ uint8_t bytes[];/**< field value */
+};
Spotted C99 syntax of flexible array.
Are we OK with all supported compilers?
Used "uint8_t *bytes;" instead of "uint8_t bytes[];"
Why this change? It is changing the size of the structure, isn't it?
It does change the size. I also agree with Adrien's comment as he
mentioned in the previous mail.
Re: [dpdk-dev] [PATCH v2 4/4] ethdev: Add metadata flow and action items support
On 05/04/2018 17:49, Thomas Monjalon wrote:
05/04/2018 15:51, Declan Doherty:
+struct rte_flow_item_metadata {
+ uint32_t id;/**< field identifier */
+ uint32_t size; /**< field size */
+ uint8_t bytes[];/**< field value */
+};
Spotted C99 syntax of flexible array.
Are we OK with all supported compilers?
Used "uint8_t *bytes;" instead of "uint8_t bytes[];"
Re: [dpdk-dev] [PATCH v2 2/4] ethdev: Add vTEP encap/decap actions
On 05/04/2018 17:42, Thomas Monjalon wrote:
05/04/2018 15:51, Declan Doherty:
+/**
+ * RTE_FLOW_ACTION_TYPE_VTEP_ENCAP
+ *
+ * Virtual tunnel end-point encapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_encap {
+ struct rte_flow_action_item {
+ enum rte_flow_item_type type;
+ /**< Flow item type. */
+ const void *item;
+ /**< Flow item definition. */
+ } *pattern;
+ /**<
+* vTEP pattern specification (list terminated by the END pattern item).
+*/
+};
+
+/**
+ * RTE_FLOW_ACTION_TYP_VTEP_DECAP
+ *
+ * Virtual tunnel end-point decapsulation action data.
+ *
+ * Non-terminating action by default.
+ */
+struct rte_flow_action_vtep_decap {
+ enum rte_flow_item_type type;
+ /**<
+* Flow item type of virtual tunnel end-point to be decapsulated
+*/
+};
Question about the naming:
Why using the terminology VTEP instead of TUNNEL simply?
I probably miss something, but tunnel encap/decap looks simpler to me.
Initial thought was that the tunnel terminology may conflict with
existing tunnel item types and their uses. In previous terminologies, it
was assumed that to create a tunneled flows, each time a tunnel item has
to be specified in the patterns.
Now with the endpoint concept, the tunnel endpoint will be created once
only, in for each subsequent flows created that is supposed to use the
tunnel, will use the tunnel metadata during the flow creation. Hence
comes the terminology virtual tunnel endpoint (VTEP). It does not harm
to use tunnel instead of vtep except the endpoint term is mission. In
the next patch TUNNEL terminology is used instead of VTEP.
Re: [dpdk-dev] [PATCH v2 1/4] ethdev: add group counter support to rte_flow
On 05/04/2018 17:31, Thomas Monjalon wrote: 05/04/2018 15:51, Declan Doherty: +Group Count Query +~ + +Query group counter which can be associated with multiple flows on a specified +port. + +This function allows retrieving of group counters. Data +is gathered by special actions which must be present in the flow rule +definition. I would like seeing an explanation of how group counter work. The guide can be more verbose than the doxygen comments. A bit elaborated explanation is as below. This function allows retrieving of group counters. A group counter is a counter which can be shared among multiple flows on a single port or among multiple flows on multiple ports within the same switch domain. Data is gathered by special actions which must be present in the flow rule definition. When the tunnel is created, the underlying PMD can keep track of the tunnel which is specified as table 0. Then each time a packet is received belongs to the tunnel, the counter is increased. During the query the counter is returned.
Re: [dpdk-dev] [PATCH 03/18] ethdev: introduce new tunnel VXLAN-GPE
On 26/02/2018 15:09, Xueming Li wrote:
diff --git a/lib/librte_net/rte_ether.h b/lib/librte_net/rte_ether.h
index 45daa91..fe02ad8 100644
--- a/lib/librte_net/rte_ether.h
+++ b/lib/librte_net/rte_ether.h
@@ -310,6 +310,31 @@ struct vxlan_hdr {
/**< VXLAN tunnel header length. */
/**
+ * VXLAN-GPE protocol header.
+ * Contains the 8-bit flag, 8-bit next-protocol, 24-bit VXLAN Network
+ * Identifier and Reserved fields (16 bits and 8 bits).
+ */
+struct vxlan_gpe_hdr {
+ uint8_t vx_flags; /**< flag (8). */
+ uint8_t reserved[2]; /**< Reserved (16). */
+ uint8_t proto; /**< next-protocol (8). */
+ uint32_t vx_vni; /**< VNI (24) + Reserved (8). */
+} __attribute__((__packed__));
+
+/* VXLAN-GPE next protocol types */
+#define VXLAN_GPE_TYPE_IPv4 1 /**< IPv4 Protocol. */
+#define VXLAN_GPE_TYPE_IPv6 2 /**< IPv6 Protocol. */
+#define VXLAN_GPE_TYPE_ETH 3 /**< Ethernet Protocol. */
+#define VXLAN_GPE_TYPE_NSH 4 /**< NSH Protocol. */
+#define VXLAN_GPE_TYPE_MPLS 5 /**< MPLS Protocol. */
+#define VXLAN_GPE_TYPE_GBP 6 /**< GBP Protocol. */
+#define VXLAN_GPE_TYPE_VBNG 7 /**< vBNG Protocol. */
+
+#define ETHER_VXLAN_GPE_HLEN (sizeof(struct udp_hdr) + \
+ sizeof(struct vxlan_gpe_hdr))
+/**< VXLAN-GPE tunnel header length. */
+
+/**
* Extract VLAN tag information into mbuf
*
* Software version of VLAN stripping
Should we define the VXLAN-GPE protocol and related macros in a separate
file (say lib/librte_net/rte_vxlan_gpe.h)?
I can see that VXLAN header also defined in the rte_ether.h file but we
should consider moving that VXLAN definition in a separate header file
(rte_vxlan.h) as well.
Regards,
Awal.
[dpdk-dev] [PATCH v2] ether: fix invalid string length in ethdev name comparison
The current code compares two strings upto the length of 1st string
(searched name). If the 1st string is prefix of 2nd string (existing name),
the string comparison returns the port_id of earliest prefix matches.
This patch fixes the bug by using strcmp instead of strncmp.
Fixes: 9c5b8d8b9fe ("ethdev: clean port id retrieval when attaching")
Signed-off-by: Mohammad Abdul Awal
---
lib/librte_ether/rte_ethdev.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0590f0c..3b885a6 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -572,8 +572,7 @@ rte_eth_dev_get_port_by_name(const char *name, uint16_t
*port_id)
for (pid = 0; pid < RTE_MAX_ETHPORTS; pid++) {
if (rte_eth_devices[pid].state != RTE_ETH_DEV_UNUSED &&
- !strncmp(name, rte_eth_dev_shared_data->data[pid].name,
-strlen(name))) {
+ !strcmp(name, rte_eth_dev_shared_data->data[pid].name)) {
*port_id = pid;
return 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH] ether: fix invalid string length in ethdev name comparison
On 27/02/2018 00:15, Ananyev, Konstantin wrote:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mohammad Abdul Awal
+ len1 = strlen(name);
for (pid = 0; pid < RTE_MAX_ETHPORTS; pid++) {
+ len2 = strlen(rte_eth_dev_shared_data->data[pid].name);
+ len = len1 > len2 ? len1 : len2;
if (rte_eth_devices[pid].state != RTE_ETH_DEV_UNUSED &&
!strncmp(name, rte_eth_dev_shared_data->data[pid].name,
-strlen(name))) {
+len)) {
Why just not simply use strcmp()? :)
That is the best I would say. I will submit a V2.
*port_id = pid;
return 0;
}
--
2.7.4
[dpdk-dev] [PATCH] ether: fix invalid string length in ethdev name comparison
The current code compares two strings upto the length of 1st string
(searched name). If the 1st string is prefix of 2nd string (existing name),
the string comparison returns the port_id of earliest prefix matches.
This patch fixes the bug by comparing the strings upto the length of larger
string.
Fixes: 9c5b8d8b9fe ("ethdev: clean port id retrieval when attaching")
Signed-off-by: Mohammad Abdul Awal
---
lib/librte_ether/rte_ethdev.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0590f0c..8e8097b 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -563,17 +563,20 @@ rte_eth_dev_get_name_by_port(uint16_t port_id, char *name)
int
rte_eth_dev_get_port_by_name(const char *name, uint16_t *port_id)
{
- uint32_t pid;
+ uint32_t pid, len, len1, len2;
if (name == NULL) {
RTE_PMD_DEBUG_TRACE("Null pointer is specified\n");
return -EINVAL;
}
+ len1 = strlen(name);
for (pid = 0; pid < RTE_MAX_ETHPORTS; pid++) {
+ len2 = strlen(rte_eth_dev_shared_data->data[pid].name);
+ len = len1 > len2 ? len1 : len2;
if (rte_eth_devices[pid].state != RTE_ETH_DEV_UNUSED &&
!strncmp(name, rte_eth_dev_shared_data->data[pid].name,
-strlen(name))) {
+len)) {
*port_id = pid;
return 0;
}
--
2.7.4
Re: [dpdk-dev] [PATCH v4 0/5] lib: add Port Representors
On 09/01/2018 22:01, Ferruh Yigit wrote: <...> The port representor infrastructure is enabled through a single common, device independent, virtual PMD whos context is initialized and enabled through a broker instance running within the context of the physical function device driver.> +-+ +-+ |rte_ethdev | | rte_ethdev| +-+ +-+ | Physical Function PMD | | Port Reperesentor PMD | | +-+ | | +-+ +-+ | | | Representor | | | | dev_data| | dev_ops | | | |Broker | | | +++ +++ | | | +-+ | | +--|---|--+ | | | VF Port | | | | | | | | Context +--+ | | | +-+ | | | | | +-+ | | | | | | Handler +--+ | | | Ops | | | | | +-+ | | | +-+ | +-+ Creation of representor ports can be achieved either through the --vdev EAL option or through the rte_vdev_init() API. Each port representor requires the BDF of it's parent PF and the Virtual Function ID of the port which the representor will support. During initialization of the representor PMD, it calls the broker API to register itself with the PF PMD and to get it's context configured which includes the setting up of it's context and ops function handlers. Above no more true, right? Right. We will rewrite these parts.
Re: [dpdk-dev] [PATCH v4 3/5] drivers/net/i40e: add Port Representor functionality
On 10/01/2018 12:37, Xing, Beilei wrote:
-Original Message-
From: Awal, Mohammad Abdul
On 10/01/2018 07:56, Xing, Beilei wrote:
<...>
+static const struct ether_addr null_mac_addr;
+
+int
+rte_pmd_i40e_remove_vf_mac_addr(uint8_t port, uint16_t vf_id,
+ struct ether_addr *mac_addr)
+{
+ struct rte_eth_dev *dev;
+ struct i40e_pf_vf *vf;
+ struct i40e_vsi *vsi;
+ struct i40e_pf *pf;
+
+ if (i40e_validate_mac_addr((u8 *)mac_addr) != I40E_SUCCESS)
+ return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+
+ if (!is_i40e_supported(dev))
+ return -ENOTSUP;
+
+ pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+
+ if (vf_id >= pf->vf_num || !pf->vfs)
+ return -EINVAL;
+
+ vf = &pf->vfs[vf_id];
+ vsi = vf->vsi;
+ if (!vsi) {
+ PMD_DRV_LOG(ERR, "Invalid VSI.");
+ return -EINVAL;
+ }
+
+ if (!is_same_ether_addr(mac_addr, &vf->mac_addr)) {
+ PMD_DRV_LOG(ERR, "Mac address does not match.");
+ return -EINVAL;
+ }
Not very understand why only vf->mac_addr can be moved?
It it checks if the mac address we want to delete, similar to the function
rte_pmd_i40e_set_vf_mac_addr where we set the mac address of a VF.
But in this way, seems we can't delete the mac address added by
rte_pmd_i40e_add_vf_mac_addr.
set_vf_mac_addr should be used for setting default mac address, right?
OK, I understand what you mean.
I have fixed it now. We reset the vf->mac_addr only if the mac address
is matched.
Then we delete it from the vsi->mac_list.
Thanks,
Awal.
I think any mac address in vsi->mac_list can be removed.
Yes, it is removed from the vsi->mac_list in the next line if the mac address is
matched in the previous checking.
+
+ /* reset the mac with null mac */
+ ether_addr_copy(&null_mac_addr, &vf->mac_addr);
Here we reset the mac address of a VF with null address, reverting the
operation of function rte_pmd_i40e_set_vf_mac_addr where we set the
mac address of a VF.
+
+ /* Remove the mac */
+ i40e_vsi_delete_mac(vsi, mac_addr);
+
+ return 0;
+}
+
Re: [dpdk-dev] [PATCH v4 3/5] drivers/net/i40e: add Port Representor functionality
On 10/01/2018 07:56, Xing, Beilei wrote:
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Remy Horton
+ dev_info->rx_offload_capa =
+ DEV_RX_OFFLOAD_VLAN_STRIP |
+ DEV_RX_OFFLOAD_QINQ_STRIP |
+ DEV_RX_OFFLOAD_IPV4_CKSUM |
+ DEV_RX_OFFLOAD_UDP_CKSUM |
+ DEV_RX_OFFLOAD_TCP_CKSUM;
+ dev_info->tx_offload_capa =
+ DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_QINQ_INSERT |
+ DEV_TX_OFFLOAD_IPV4_CKSUM |
+ DEV_TX_OFFLOAD_UDP_CKSUM |
+ DEV_TX_OFFLOAD_TCP_CKSUM |
+ DEV_TX_OFFLOAD_SCTP_CKSUM;
Tunnel TSO and outer IP checksum are also supported.
Correct. Fixed.
<...>
+static const struct ether_addr null_mac_addr;
+
+int
+rte_pmd_i40e_remove_vf_mac_addr(uint8_t port, uint16_t vf_id,
+ struct ether_addr *mac_addr)
+{
+ struct rte_eth_dev *dev;
+ struct i40e_pf_vf *vf;
+ struct i40e_vsi *vsi;
+ struct i40e_pf *pf;
+
+ if (i40e_validate_mac_addr((u8 *)mac_addr) != I40E_SUCCESS)
+ return -EINVAL;
+
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV);
+
+ dev = &rte_eth_devices[port];
+
+ if (!is_i40e_supported(dev))
+ return -ENOTSUP;
+
+ pf = I40E_DEV_PRIVATE_TO_PF(dev->data->dev_private);
+
+ if (vf_id >= pf->vf_num || !pf->vfs)
+ return -EINVAL;
+
+ vf = &pf->vfs[vf_id];
+ vsi = vf->vsi;
+ if (!vsi) {
+ PMD_DRV_LOG(ERR, "Invalid VSI.");
+ return -EINVAL;
+ }
+
+ if (!is_same_ether_addr(mac_addr, &vf->mac_addr)) {
+ PMD_DRV_LOG(ERR, "Mac address does not match.");
+ return -EINVAL;
+ }
Not very understand why only vf->mac_addr can be moved?
It it checks if the mac address we want to delete, similar to the
function rte_pmd_i40e_set_vf_mac_addr where we set the mac address of a VF.
I think any mac address in vsi->mac_list can be removed.
Yes, it is removed from the vsi->mac_list in the next line if the mac
address is matched in the previous checking.
+
+ /* reset the mac with null mac */
+ ether_addr_copy(&null_mac_addr, &vf->mac_addr);
Here we reset the mac address of a VF with null address, reverting the
operation of function rte_pmd_i40e_set_vf_mac_addr where we set the mac
address of a VF.
+
+ /* Remove the mac */
+ i40e_vsi_delete_mac(vsi, mac_addr);
+
+ return 0;
+}
+
Re: [dpdk-dev] [DPDK 0/5] lib: add Port Representors
Hi Neil, On 22/12/2017 16:37, Neil Horman wrote: On Fri, Dec 22, 2017 at 02:41:16PM +, Remy Horton wrote: Port Representors provide a logical presentation in DPDK of VF (virtual function) ports for the purposes of control and monitoring. Each port representor device represents a single VF and is associated with it's parent physical function (PF) PMD which provides the back-end hooks for the representor device ops and defines the control domain to which that port belongs. This allows to use existing DPDK APIs to monitor and control the port without the need to create and maintain VF specific APIs. +-+ +---+ +---+ |Control Plane| | Data Plane | | Data Plane | | Application | | Application | | Application | +-+ +---+ +---+ | eth dev api | | eth dev api | | eth dev api | +-+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | PF0 | | Port | | Port | |VF0 PMD| |VF0 PMD| | PMD <--+ Rep 0 | | Rep 1 | +---+ +--++ | | | PMD | | PMD | | +---+--^+ +---+ +-+-+ | | || || | ++ || | || | || ++ | | | HW (logical view) | | | | --+--+ +---+ +---+---+ | | | | PF | | VF0 | | VF1 | | | | || | | | ++ | ++ +---+ +---+ | | ++ | | |VEB | | | ++ | | ++ | | | Port | | | | 0| | | ++ | ++ How does this mesh with the notion of port ownership that we've been discussing in other threads? In that thread, we've been discussing the need for a single execution context to have exclusive access to the hardware for the purposes of configuration and data i/o, and for the application/execution context to be responsible for co-ordination of any shared use of a device. In this feature however, the notion of a Port Representor creates an alias to the same hardware funciton (VF), where both aliases (in the control and data plan) have parallel access to the hardware, in such a way that co-ordination between the two is largely impossible (unless you want to make the data plane application explicity aware of control plane actiivy). Neil I have just replied to your mail in other thread of V3 patch. Regards, Awal.
Re: [dpdk-dev] [PATCH v3 0/5] lib: add Port Representors
Hi Neil, On 26/12/2017 13:54, Neil Horman wrote: On Fri, Dec 22, 2017 at 02:52:16PM +, Remy Horton wrote: Port Representors provide a logical presentation in DPDK of VF (virtual function) ports for the purposes of control and monitoring. Each port representor device represents a single VF and is associated with it's parent physical function (PF) PMD which provides the back-end hooks for the representor device ops and defines the control domain to which that port belongs. This allows to use existing DPDK APIs to monitor and control the port without the need to create and maintain VF specific APIs. +-+ +---+ +---+ |Control Plane| | Data Plane | | Data Plane | | Application | | Application | | Application | +-+ +---+ +---+ | eth dev api | | eth dev api | | eth dev api | +-+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | PF0 | | Port | | Port | |VF0 PMD| |VF0 PMD| | PMD <--+ Rep 0 | | Rep 1 | +---+ +--++ | | | PMD | | PMD | | +---+--^+ +---+ +-+-+ | | || || | ++ || | || | || ++ | | | HW (logical view) | | | | --+--+ +---+ +---+---+ | | | | PF | | VF0 | | VF1 | | | | || | | | ++ | ++ +---+ +---+ | | ++ | | |VEB | | | ++ | | ++ | | | Port | | | | 0| | | ++ | ++ The figure above shows a deployment where the PF is bound to a DPDK control plane application which uses representor ports to manage the configuration and monitoring of it's VF ports. Each virtual function is represented in the application by a representor port PMD which enables control of the corresponding VF through eth dev APIs on the representor PMD such as: - void rte_eth_promiscuous_enable(uint8_t port_id); - void rte_eth_promiscuous_disable(uint8_t port_id); - void rte_eth_allmulticast_enable(uint8_t port_id); - void rte_eth_allmulticast_disable(uint8_t port_id); - int rte_eth_dev_mac_addr_add(uint8_t port, struct ether_addr *mac_addr, uint32_t pool); - int rte_eth_dev_set_vlan_offload(uint8_t port_id, int offload_mask); as well as monitoring through API's like - void rte_eth_link_get(uint8_t port_id, struct rte_eth_link *link); - int rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats *stats); The port representor infrastructure is enabled through a single common, device independent, virtual PMD whos context is initialized and enabled through a broker instance running within the context of the physical function device driver. +-+ +-+ |rte_ethdev | | rte_ethdev| +-+ +-+ | Physical Function PMD | | Port Reperesentor PMD | | +-+ | | +-+ +-+ | | | Representor | | | | dev_data| | dev_ops | | | |Broker | | | +++ +++ | | | +-+ | | +--|---|--+ | | | VF Port | | | | | | | | Context +--+ | | | +-+ | | | | | +-+ | | | | | | Handler +--+ | | | Ops | | | | | +-+ | | | +-+ | +-+ Creation of representor ports can be achieved either through the --vdev EAL option or through the rte_vdev_init() API. Each port representor requires the BDF of it's parent PF and the Virtual Function ID of the port which the representor will support. During initialization of the representor PMD, it calls the broker API to register itself with the PF PMD and to get it's context configured which includes the setting up of it's context and ops function handlers. As the port representor model is based around the paradigm of using standard port based APIs, it will allow future expansion of functionality without the need to add new APIs. For example it should be possible to support conf
Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
On 27/12/2017 15:50, Alex Rosenbaum wrote: On Wed, Dec 27, 2017 at 11:40 AM, Mohammad Abdul Awal wrote: On 22/12/2017 22:33, Alex Rosenbaum wrote: On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal On 21/12/2017 14:51, Alex Rosenbaum wrote: By hotplug I did not mean HW hotplug, rather I meant the software hotplug of port representor so that an application can add/delete representor at run time. What is the expect results if application adds/deletes a representor at run time? From my understanding, for OVS, it would make much sense to enumerate the representors during the startup time and only 'state' active/inactive would enough to imply the state of a VF. On the other hand, for a system with varieties of NICs/FPGAs/SmartNics having capacities of hundreds (if not thousands) of max VFs and different capabilities, we may not want to allocate them if not being using, and we may not be able to control this way if no broker. This is definitely a matter of design discussion for now where ultimate outcome is same, i.e. having a representor to control a VF. I would expect the VF hotplug to be depended on the PF configuration. So that new/removed VF's would trigger a representor state or existance. I agree and as I have just said above that it is different ways of doing same thing with limited/flexible ability. Alex Regards, Awal
Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
On 22/12/2017 22:33, Alex Rosenbaum wrote: On Fri, Dec 22, 2017 at 4:31 PM, Mohammad Abdul Awal wrote: On 21/12/2017 14:51, Alex Rosenbaum wrote: As described in the links Alejandro referenced earlier, each of the switch ports should be a real PMD, and switch operations should be applied on these PMD ports. This includes the steering redirection of traffic between switch ports [1], port ACL's to block/allow traffic, VST/VGT modes and anti spoofing, link trust mode [3] for promiscuous configuration, mirroring of switch port traffic, and Tx and Rx of switch port traffic to/from VF's port. I agree that we need a switch_domain parameter. At the moment we do not have APIs implemented for all the switch operations you have mentioned above. So, we are planning separate RFC with switch _domain and related APIs. Sure, we can extend these switch ops in a separate step. More over, building this as real PMD ports of a switch device removes the need to add a new broker framework all together. Each vendor just needs to map additional PMD ports during the probing stage. That is very much possible as well. If we agree to probe all the ports during the initialization phase, we can have all the representors ready without any interaction from application and broker. On the other hand, we may require a broker structure to enable hotplug support. hotplug should be supported for any PMD ports, and any BDF type. I don't understand why do you need the broker framework in order to support hotplug? By hotplug I did not mean HW hotplug, rather I meant the software hotplug of port representor so that an application can add/delete representor at run time. Regards, Awal. Alex
Re: [dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
Hi ALex, On 21/12/2017 14:51, Alex Rosenbaum wrote: Declan, Mohammad, The submission [1] of steering action between switch ports clearly requires a switch model in DPDK. The Port Representor based on a virtual PMD broker on NIC ops (rte_dev_ops) does not provide the required functionality. Using NIC terminology and not Switch API's will lead to a dead-end. Moreover, it does not fit the Kernel design. We need to be careful from this ending up as two different deployment models for users, which is very bad. There was a long discussion about this in netdev ML [2], including the VEPA mode support. As described in the links Alejandro referenced earlier, each of the switch ports should be a real PMD, and switch operations should be applied on these PMD ports. This includes the steering redirection of traffic between switch ports [1], port ACL's to block/allow traffic, VST/VGT modes and anti spoofing, link trust mode [3] for promiscuous configuration, mirroring of switch port traffic, and Tx and Rx of switch port traffic to/from VF's port. I agree that we need a switch_domain parameter. At the moment we do not have APIs implemented for all the switch operations you have mentioned above. So, we are planning separate RFC with switch _domain and related APIs. More over, building this as real PMD ports of a switch device removes the need to add a new broker framework all together. Each vendor just needs to map additional PMD ports during the probing stage. That is very much possible as well. If we agree to probe all the ports during the initialization phase, we can have all the representors ready without any interaction from application and broker. On the other hand, we may require a broker structure to enable hotplug support. By adding a switchdev_id we can define these are ports associated to the same switching device, and can allow new port and inter-port actions. [1] http://dpdk.org/dev/patchwork/patch/32550/ [2] https://www.spinics.net/lists/netdev/msg467375.html [2] https://www.systutorials.com/docs/linux/man/8-ip-link/ Alex Regards, Awal.
Re: [dpdk-dev] [PATCH v2 1/6] ethdev: added switch_domain and representor port flag
Hi Alex, On 11/12/2017 13:45, Alex Rosenbaum wrote: Mohammad, I did not see a v2 change log. did I miss it? please send. The V2 change is for vdev handling by the representor PMD as the vdev API location changed from DPDK 17.08 to 17.11. So, V2 patch mainly a rebased against DPDK 17.11. I don't understand who this v2 addresses the comments by Alejandro Lucero from netronome [1]. These are critical points which your proposal does not handle. It is related to the switch_domain member exposed here. Since, none of the initial NICs (i40e, ixgbe) is using switch_domain for the moment, we are dropping the switch_domain from these patch set. It is expected to be address in future patchset with switchdev support. Regards, Awal. thanks, Alex [1] http://dpdk.org/ml/archives/dev/2017-September/074904.html
Re: [dpdk-dev] [PATCH v2 4/6] net/representor: Implement port representor PMD
On 11/12/2017 10:08, Remy Horton wrote: int rte_representor_port_register(const char *devargs); Question is where this *devargs comes from - I don't think there is currently any commandline option to specify a parameter string for PFs. Remy, devargs will be passed by the application who uses the rte_representor_port_register API. We are not talking about the EAL args here. Could go down the zero-conf route of always creating representors for all available VFs, but in that case may as well strip out the parsing code. No zero-conf please. Application should have the control, at least for generic cases.
Re: [dpdk-dev] [PATCH v2 4/6] net/representor: Implement port representor PMD
On 08/12/2017 15:02, Remy Horton wrote: On 20/11/2017 07:46, Ferruh Yigit wrote: [..] Why we need this PMD? It looks like this has been used only for parameter parsing. Can it be possible to rte_representor_broker_init() will allocate ethdevs and fill brokers with this information? Possible, but not sure it gains much in practice. It would require workarounds to avoid pulling in driver code dependencies (e.g. drivers/bus/vdev/rte_bus_vdev.h). I think it possible to create the representor without pulling in driver codes. We probably can avoid using the rte_eth_vdev_allocate by calling the rte_eth_dev_allocate() directly. Right now, the port representor register API looks like int rte_representor_port_register(struct rte_representor_broker *broker, uint32_t vport_id, struct rte_eth_dev *ethdev); So, we probably can have that API (and make it public) as below. int rte_representor_port_register(const char *devargs); We can parse the devargs to get all the parameters, create the ethdev using rte_eth_dev_allocate(), fill all the private data, pci_device, pci_driver etc. and register to the broker. This way we can avoid having a separate PMD for port representor. This comes with a limitation/benefit that user do need need to pass the vdev info as EAL argument. Regards, Awal.
Re: [dpdk-dev] [PATCH v2 1/6] ethdev: added switch_domain and representor port flag
On 20/11/2017 19:57, Ferruh Yigit wrote:
On 11/17/2017 6:42 AM, Mohammad Abdul Awal wrote:
switch_domain attribute has been added to specify that a rte_eth_dev
instance belongs to a switch domain in the software switch.
RTE_ETH_DEV_REPRESENTOR_PORT has been defined to specify that a
rte_eth_dev instance is a representor device.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Declan Doherty
---
lib/librte_ether/rte_ethdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 341c2d6..7e82c70 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
/** Configured number of rx/tx queues */
uint16_t nb_rx_queues; /**< Number of RX queues. */
uint16_t nb_tx_queues; /**< Number of TX queues. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
What to put or not into rte_eth_dev_info is not that clear, but recent
description from Andrew [1] makes sense to me: using more device related static
information in dev_info instead of dynamic data.
There is an option to create a new API for this, what do you think?
[1]
http://dpdk.org/ml/archives/dev/2017-November/081868.html
};
/**
@@ -1810,6 +1811,7 @@ struct rte_eth_dev_data {
int numa_node; /**< NUMA node connection */
struct rte_vlan_filter_conf vlan_filter_conf;
/**< VLAN filter configuration. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
Can you please describe why "switch_domain" used for? In patchset only ixgbe
uses it, and that is only for assign to dev_info, it is not clear why this is
needed.
We kept it keeping in mind for future use, specially for switchdev API
and OVS support. But for this patch it is not necessary to be here. We
will remove it from here now. New patch will be submitted if needed in
future.
};
/** Device supports link state interrupt */
@@ -1818,6 +1820,8 @@ struct rte_eth_dev_data {
#define RTE_ETH_DEV_BONDED_SLAVE 0x0004
/** Device supports device removal interrupt */
#define RTE_ETH_DEV_INTR_RMV 0x0008
+/** Device is a port representor */
+#define RTE_ETH_DEV_REPRESENTOR_PORT 0x0010
As far as I can see this is not a generic device option, but just a way to mark
a specific virtual PMD. There must be a better way to do this, I think this flag
is not good idea.
Thanks Ferruh. We will also remove this flag option. Without this flag
option, we can still identify the PMD as a port representor type or not
by looking at the device name.
/**
* @internal
Re: [dpdk-dev] [PATCH v2 2/6] lib/representor: port representor library to manage broker infrastructure and representor PMDs
On 17/11/2017 23:03, Ferruh Yigit wrote:
On 11/17/2017 6:42 AM, Mohammad Abdul Awal wrote:
diff --git a/lib/librte_representor/rte_port_representor_version.map
b/lib/librte_representor/rte_port_representor_version.map
new file mode 100644
index 000..09ed768
--- /dev/null
+++ b/lib/librte_representor/rte_port_representor_version.map
@@ -0,0 +1,12 @@
+DPDK_18.02 {2 {
+ global:
+
+ rte_representor_broker_find;
+ rte_representor_broker_init;
+ rte_representor_broker_uninit;
+ rte_representor_port_get_vport_id;
+ rte_representor_port_register;
+ rte_representor_port_unregister;
Is any of these APIs intended to be used by application?
From rest of the patch it looks like these are used by PMDs, if so why creating
a new library?
These API's are to be used by PMDs only. We will remove them from here.
Thanks,
Awal.
+
+ local: *;
+};
[dpdk-dev] [PATCH v2 6/6] net/ixgbe: Enable port representor PMD and broker for ixgbe PMD driver
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/ixgbe/Makefile | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 22 +++-
drivers/net/ixgbe/ixgbe_ethdev.h | 6 +
drivers/net/ixgbe/ixgbe_prep_ops.c | 250 +
drivers/net/ixgbe/ixgbe_prep_ops.h | 46 +++
5 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.c
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.h
diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index 511a64e..4ec2422 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -130,6 +130,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_ipsec.c
endif
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += rte_pmd_ixgbe.c
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)-include := rte_pmd_ixgbe.h
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index ff19a56..a48b783 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -75,6 +75,7 @@
#include "base/ixgbe_type.h"
#include "base/ixgbe_phy.h"
#include "ixgbe_regs.h"
+#include "ixgbe_prep_ops.h"
/*
* High threshold controlling when to start sending XOFF frames. Must be at
@@ -1138,6 +1139,9 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
uint32_t ctrl_ext;
uint16_t csum;
int diag, i;
+ int ret;
+ struct ixgbe_adapter *eth_adapter =
+ (struct ixgbe_adapter *)eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1261,6 +1265,17 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
return -EIO;
}
+ /* Init port representor broker */
+ if (rte_representor_enabled()) {
+ ret = ixgbe_port_representor_broker_init(eth_dev,
+ ð_adapter->broker, pci_dev);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Representor broker register failed "
+ "with ret=%d\n", ret);
+ return ret;
+ }
+ }
+
/* Reset the hw statistics */
ixgbe_dev_stats_reset(eth_dev);
@@ -1363,6 +1378,8 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
struct ixgbe_hw *hw;
+ struct ixgbe_adapter *eth_adapter =
+ (struct ixgbe_adapter *)eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1371,6 +1388,9 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
hw = IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ if (rte_representor_enabled())
+ rte_representor_broker_uninit(eth_adapter->broker);
+
if (hw->adapter_stopped == 0)
ixgbe_dev_close(eth_dev);
@@ -3962,7 +3982,7 @@ ixgbevf_check_link(struct ixgbe_hw *hw, ixgbe_link_speed
*speed,
}
/* return 0 means link status changed, -1 means not changed */
-static int
+int
ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
int wait_to_complete, int vf)
{
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 51ddcfd..ae1e790 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -499,6 +499,7 @@ struct ixgbe_adapter {
struct rte_timecounter rx_tstamp_tc;
struct rte_timecounter tx_tstamp_tc;
struct ixgbe_tm_conftm_conf;
+ struct rte_representor_broker *broker;
};
#define IXGBE_DEV_PRIVATE_TO_HW(adapter)\
@@ -673,6 +674,11 @@ int ixgbe_fdir_filter_program(struct rte_eth_dev *dev,
void ixgbe_configure_dcb(struct rte_eth_dev *dev);
+int
+ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
+ int wait_to_complete, int vf);
+
+
/*
* misc function prototypes
*/
diff --git a/drivers/net/ixgbe/ixgbe_prep_ops.c
b/drivers/net/ixgbe/ixgbe_prep_ops.c
new file mode 100644
index 000..ac57f8b
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_prep_ops.c
@@ -0,0 +1,250 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Corporation. 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
[dpdk-dev] [PATCH v2 5/6] net/i40e: Enable port representor PMD and broker for fortville PMD driver
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/i40e/Makefile| 1 +
drivers/net/i40e/i40e_ethdev.c | 16 ++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_prep_ops.c | 472 +++
drivers/net/i40e/i40e_prep_ops.h | 46
drivers/net/i40e/rte_pmd_i40e.c | 47
drivers/net/i40e/rte_pmd_i40e.h | 18 ++
7 files changed, 601 insertions(+)
create mode 100644 drivers/net/i40e/i40e_prep_ops.c
create mode 100644 drivers/net/i40e/i40e_prep_ops.h
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 9ab8c84..641bf26 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -113,6 +113,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_flow.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += rte_pmd_i40e.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_I40E_PMD)-include := rte_pmd_i40e.h
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 811cc9f..65bb320 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -67,6 +67,7 @@
#include "i40e_pf.h"
#include "i40e_regs.h"
#include "rte_pmd_i40e.h"
+#include "i40e_prep_ops.h"
#define ETH_I40E_FLOATING_VEB_ARG "enable_floating_veb"
#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
@@ -1122,6 +1123,17 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
hw->bus.func = pci_dev->addr.function;
hw->adapter_stopped = 0;
+ /* init representor broker */
+ if (rte_representor_enabled()) {
+ ret = i40e_port_representor_broker_init(dev, &pf->broker,
+ pci_dev);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Representor broker register failed "
+ "with ret=%d\n", ret);
+ return ret;
+ }
+ }
+
/* Make sure all is clean before doing PF reset */
i40e_clear_hw(hw);
@@ -1457,6 +1469,10 @@ eth_i40e_dev_uninit(struct rte_eth_dev *dev)
pci_dev = RTE_ETH_DEV_TO_PCI(dev);
intr_handle = &pci_dev->intr_handle;
+ /* free port representor pmds */
+ if (rte_representor_enabled())
+ rte_representor_broker_uninit(pf->broker);
+
if (hw->adapter_stopped == 0)
i40e_dev_close(dev);
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index cd67453..9e962eb 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -957,6 +957,7 @@ struct i40e_pf {
bool gtp_replace_flag; /* 1 - GTP-C/U filter replace is done */
bool qinq_replace_flag; /* QINQ filter replace is done */
struct i40e_tm_conf tm_conf;
+ struct rte_representor_broker *broker;
/* Dynamic Device Personalization */
bool gtp_support; /* 1 - support GTP-C and GTP-U */
diff --git a/drivers/net/i40e/i40e_prep_ops.c b/drivers/net/i40e/i40e_prep_ops.c
new file mode 100644
index 000..3261b97
--- /dev/null
+++ b/drivers/net/i40e/i40e_prep_ops.c
@@ -0,0 +1,472 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 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
[dpdk-dev] [PATCH v2 1/6] ethdev: added switch_domain and representor port flag
switch_domain attribute has been added to specify that a rte_eth_dev
instance belongs to a switch domain in the software switch.
RTE_ETH_DEV_REPRESENTOR_PORT has been defined to specify that a
rte_eth_dev instance is a representor device.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Declan Doherty
---
lib/librte_ether/rte_ethdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 341c2d6..7e82c70 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
/** Configured number of rx/tx queues */
uint16_t nb_rx_queues; /**< Number of RX queues. */
uint16_t nb_tx_queues; /**< Number of TX queues. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
};
/**
@@ -1810,6 +1811,7 @@ struct rte_eth_dev_data {
int numa_node; /**< NUMA node connection */
struct rte_vlan_filter_conf vlan_filter_conf;
/**< VLAN filter configuration. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
};
/** Device supports link state interrupt */
@@ -1818,6 +1820,8 @@ struct rte_eth_dev_data {
#define RTE_ETH_DEV_BONDED_SLAVE 0x0004
/** Device supports device removal interrupt */
#define RTE_ETH_DEV_INTR_RMV 0x0008
+/** Device is a port representor */
+#define RTE_ETH_DEV_REPRESENTOR_PORT 0x0010
/**
* @internal
--
2.7.4
[dpdk-dev] [PATCH v2 3/6] eal: added --enable-representor command line argument in EAL to load representor broker infrastructure
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Declan Doherty
---
lib/librte_eal/bsdapp/eal/eal.c| 6 ++
lib/librte_eal/common/eal_common_options.c | 1 +
lib/librte_eal/common/eal_internal_cfg.h | 2 ++
lib/librte_eal/common/eal_options.h| 2 ++
lib/librte_eal/common/include/rte_eal.h| 8
lib/librte_eal/linuxapp/eal/eal.c | 9 +
6 files changed, 28 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 369a682..002200a 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -778,3 +778,9 @@ int rte_vfio_noiommu_is_enabled(void)
{
return 0;
}
+
+/* return non-zero if port-representor is enabled. */
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 996a034..6f2cc05 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -78,6 +78,7 @@ const struct option
eal_long_options[] = {
{OPT_BASE_VIRTADDR, 1, NULL, OPT_BASE_VIRTADDR_NUM},
{OPT_CREATE_UIO_DEV,0, NULL, OPT_CREATE_UIO_DEV_NUM },
+ {OPT_ENABLE_REPRESENTOR, 0, NULL, OPT_ENABLE_REPRESENTOR_NUM },
{OPT_FILE_PREFIX, 1, NULL, OPT_FILE_PREFIX_NUM },
{OPT_HELP, 0, NULL, OPT_HELP_NUM },
{OPT_HUGE_DIR, 1, NULL, OPT_HUGE_DIR_NUM },
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index fa6ccbe..55cae8c 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -71,6 +71,8 @@ struct internal_config {
* instead of native TSC */
volatile unsigned no_shconf; /**< true if there is no shared
config */
volatile unsigned create_uio_dev; /**< true to create /dev/uioX devices
*/
+ volatile unsigned enable_representor;
+ /**< true to enable port representor broker for all PFs */
volatile enum rte_proc_type_t process_type; /**< multi-process proc
type */
/** true to try allocating memory on specific sockets */
volatile unsigned force_sockets;
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index 30e6bb4..c2b2162 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VFIO_INTR_NUM,
#define OPT_VMWARE_TSC_MAP"vmware-tsc-map"
OPT_VMWARE_TSC_MAP_NUM,
+#define OPT_ENABLE_REPRESENTOR"enable-representor"
+ OPT_ENABLE_REPRESENTOR_NUM,
OPT_LONG_MAX_NUM
};
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index 8e4e71c..c4e61d1 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -335,6 +335,14 @@ enum rte_iova_mode rte_eal_iova_mode(void);
const char *
rte_eal_mbuf_default_mempool_ops(void);
+/**
+ * Get flag for port representor should be enabled or not.
+ *
+ * @return
+ * Returns the enable-representor flag.
+ */
+int rte_representor_enabled(void);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 229eec9..364a8b2 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -612,6 +612,10 @@ eal_parse_args(int argc, char **argv)
internal_config.mbuf_pool_ops_name = optarg;
break;
+ case OPT_ENABLE_REPRESENTOR_NUM:
+ internal_config.enable_representor = 1;
+ break;
+
default:
if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
RTE_LOG(ERR, EAL, "Option %c is not supported "
@@ -1041,3 +1045,8 @@ rte_eal_check_module(const char *module_name)
/* Module has been found */
return 1;
}
+
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
--
2.7.4
[dpdk-dev] [PATCH v2 4/6] net/representor: Implement port representor PMD
V2: Update rte_bus_vdev.h header file instead of rte_vdev.h file. V1: Representor PMD is a virtual PMD which provides a logical representation in DPDK for ports of a multi port device. This supports configuration, management, and monitoring of VFs of a physical function bound to a userspace control plane application. Change-Id: I5a7834bbc05bc9037e3218f69f10c1bd1e787236 Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- drivers/net/Makefile | 1 + drivers/net/representor/Makefile | 52 drivers/net/representor/port_representor.c | 323 + .../representor/rte_pmd_representor_version.map| 4 + mk/rte.app.mk | 1 + 5 files changed, 381 insertions(+) create mode 100644 drivers/net/representor/Makefile create mode 100644 drivers/net/representor/port_representor.c create mode 100644 drivers/net/representor/rte_pmd_representor_version.map diff --git a/drivers/net/Makefile b/drivers/net/Makefile index ef09b4e..068a254 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -68,6 +68,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += tap DIRS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += thunderx DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3 +DIRS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += representor ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) DIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += kni diff --git a/drivers/net/representor/Makefile b/drivers/net/representor/Makefile new file mode 100644 index 000..5647045 --- /dev/null +++ b/drivers/net/representor/Makefile @@ -0,0 +1,52 @@ +# BSD LICENSE +# +# Copyright(c) 2017 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. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_representor.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_representor + +EXPORT_MAP := rte_pmd_representor_version.map + +LIBABIVER := 1 + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += port_representor.c + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/drivers/net/representor/port_representor.c b/drivers/net/representor/port_representor.c new file mode 100644 index 000..8e75b21 --- /dev/null +++ b/drivers/net/representor/port_representor.c @@ -0,0 +1,323 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. 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 WARRAN
[dpdk-dev] [PATCH v2 2/6] lib/representor: port representor library to manage broker infrastructure and representor PMDs
The library provides the broker infrastructure to be instantiated by base driver and corresponding methods to manage the broker infrastructure. The broker keeps records of list of representor PMDs. The library also provides methods to manage the representor PMDs by the broker. Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- config/common_base | 5 + lib/Makefile | 3 + lib/librte_representor/Makefile| 53 ++ lib/librte_representor/rte_port_representor.c | 212 + .../rte_port_representor_driver.h | 183 ++ .../rte_port_representor_version.map | 12 ++ mk/rte.app.mk | 1 + 7 files changed, 469 insertions(+) create mode 100644 lib/librte_representor/Makefile create mode 100644 lib/librte_representor/rte_port_representor.c create mode 100644 lib/librte_representor/rte_port_representor_driver.h create mode 100644 lib/librte_representor/rte_port_representor_version.map diff --git a/config/common_base b/config/common_base index e74febe..febb80a 100644 --- a/config/common_base +++ b/config/common_base @@ -820,3 +820,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y # Compile the eventdev application # CONFIG_RTE_APP_EVENTDEV=y + +# +# Compile representor PMD +# +CONFIG_RTE_LIBRTE_REPRESENTOR=y diff --git a/lib/Makefile b/lib/Makefile index dc4e8df..b9202ff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -101,6 +101,9 @@ DEPDIRS-librte_distributor := librte_eal librte_mbuf librte_ether DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port DEPDIRS-librte_port := librte_eal librte_mempool librte_mbuf librte_ether DEPDIRS-librte_port += librte_ip_frag librte_sched +DIRS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += librte_representor +DEPDIRS-librte_representor += librte_ether + ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) DEPDIRS-librte_port += librte_kni endif diff --git a/lib/librte_representor/Makefile b/lib/librte_representor/Makefile new file mode 100644 index 000..09d29f7 --- /dev/null +++ b/lib/librte_representor/Makefile @@ -0,0 +1,53 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2017 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. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_representor.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_port_representor_version.map + +LIBABIVER := 1 + +SRCS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += rte_port_representor.c + +# +# Export include files +# +SYMLINK-$(CONFIG_RTE_LIBRTE_REPRESENTOR)-include += rte_port_representor_driver.h + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_representor/rte_port_representor.c b/lib/librte_representor/rte_port_representor.c new file mode 100644 index 000..f8debea --- /dev/null +++ b/lib/librte_representor/rte_port_representor.c @@ -0,0 +1,212 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. 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
[dpdk-dev] [PATCH 6/6] net/ixgbe: Enable port representor PMD and broker for ixgbe PMD driver
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/ixgbe/Makefile | 1 +
drivers/net/ixgbe/ixgbe_ethdev.c | 22 +++-
drivers/net/ixgbe/ixgbe_ethdev.h | 6 +
drivers/net/ixgbe/ixgbe_prep_ops.c | 250 +
drivers/net/ixgbe/ixgbe_prep_ops.h | 46 +++
5 files changed, 324 insertions(+), 1 deletion(-)
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.c
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.h
diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index 511a64e..4ec2422 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -130,6 +130,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_ipsec.c
endif
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += rte_pmd_ixgbe.c
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)-include := rte_pmd_ixgbe.h
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index b985585..0446020 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -76,6 +76,7 @@
#include "base/ixgbe_type.h"
#include "base/ixgbe_phy.h"
#include "ixgbe_regs.h"
+#include "ixgbe_prep_ops.h"
/*
* High threshold controlling when to start sending XOFF frames. Must be at
@@ -1139,6 +1140,9 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
uint32_t ctrl_ext;
uint16_t csum;
int diag, i;
+ int ret;
+ struct ixgbe_adapter *eth_adapter =
+ (struct ixgbe_adapter *)eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1262,6 +1266,17 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
return -EIO;
}
+ /* Init port representor broker */
+ if (rte_representor_enabled()) {
+ ret = ixgbe_port_representor_broker_init(eth_dev,
+ ð_adapter->broker, pci_dev);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Representor broker register failed "
+ "with ret=%d\n", ret);
+ return ret;
+ }
+ }
+
/* Reset the hw statistics */
ixgbe_dev_stats_reset(eth_dev);
@@ -1364,6 +1379,8 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
struct rte_pci_device *pci_dev = RTE_ETH_DEV_TO_PCI(eth_dev);
struct rte_intr_handle *intr_handle = &pci_dev->intr_handle;
struct ixgbe_hw *hw;
+ struct ixgbe_adapter *eth_adapter =
+ (struct ixgbe_adapter *)eth_dev->data->dev_private;
PMD_INIT_FUNC_TRACE();
@@ -1372,6 +1389,9 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
hw = IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ if (rte_representor_enabled())
+ rte_representor_broker_uninit(eth_adapter->broker);
+
if (hw->adapter_stopped == 0)
ixgbe_dev_close(eth_dev);
@@ -3963,7 +3983,7 @@ ixgbevf_check_link(struct ixgbe_hw *hw, ixgbe_link_speed
*speed,
}
/* return 0 means link status changed, -1 means not changed */
-static int
+int
ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
int wait_to_complete, int vf)
{
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.h b/drivers/net/ixgbe/ixgbe_ethdev.h
index 51ddcfd..ae1e790 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.h
+++ b/drivers/net/ixgbe/ixgbe_ethdev.h
@@ -499,6 +499,7 @@ struct ixgbe_adapter {
struct rte_timecounter rx_tstamp_tc;
struct rte_timecounter tx_tstamp_tc;
struct ixgbe_tm_conftm_conf;
+ struct rte_representor_broker *broker;
};
#define IXGBE_DEV_PRIVATE_TO_HW(adapter)\
@@ -673,6 +674,11 @@ int ixgbe_fdir_filter_program(struct rte_eth_dev *dev,
void ixgbe_configure_dcb(struct rte_eth_dev *dev);
+int
+ixgbe_dev_link_update_share(struct rte_eth_dev *dev,
+ int wait_to_complete, int vf);
+
+
/*
* misc function prototypes
*/
diff --git a/drivers/net/ixgbe/ixgbe_prep_ops.c
b/drivers/net/ixgbe/ixgbe_prep_ops.c
new file mode 100644
index 000..ac57f8b
--- /dev/null
+++ b/drivers/net/ixgbe/ixgbe_prep_ops.c
@@ -0,0 +1,250 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 Intel Corporation. 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
[dpdk-dev] [PATCH 5/6] net/i40e: Enable port representor PMD and broker for fortville PMD driver
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/i40e/Makefile| 1 +
drivers/net/i40e/i40e_ethdev.c | 16 ++
drivers/net/i40e/i40e_ethdev.h | 1 +
drivers/net/i40e/i40e_prep_ops.c | 472 +++
drivers/net/i40e/i40e_prep_ops.h | 46
drivers/net/i40e/rte_pmd_i40e.c | 47
drivers/net/i40e/rte_pmd_i40e.h | 18 ++
7 files changed, 601 insertions(+)
create mode 100644 drivers/net/i40e/i40e_prep_ops.c
create mode 100644 drivers/net/i40e/i40e_prep_ops.h
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 9ab8c84..641bf26 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -113,6 +113,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_flow.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += rte_pmd_i40e.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_I40E_PMD)-include := rte_pmd_i40e.h
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index bcd9ef1..00ffe6b 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -67,6 +67,7 @@
#include "i40e_pf.h"
#include "i40e_regs.h"
#include "rte_pmd_i40e.h"
+#include "i40e_prep_ops.h"
#define ETH_I40E_FLOATING_VEB_ARG "enable_floating_veb"
#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
@@ -1122,6 +1123,17 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
hw->bus.func = pci_dev->addr.function;
hw->adapter_stopped = 0;
+ /* init representor broker */
+ if (rte_representor_enabled()) {
+ ret = i40e_port_representor_broker_init(dev, &pf->broker,
+ pci_dev);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "Representor broker register failed "
+ "with ret=%d\n", ret);
+ return ret;
+ }
+ }
+
/* Make sure all is clean before doing PF reset */
i40e_clear_hw(hw);
@@ -1457,6 +1469,10 @@ eth_i40e_dev_uninit(struct rte_eth_dev *dev)
pci_dev = RTE_ETH_DEV_TO_PCI(dev);
intr_handle = &pci_dev->intr_handle;
+ /* free port representor pmds */
+ if (rte_representor_enabled())
+ rte_representor_broker_uninit(pf->broker);
+
if (hw->adapter_stopped == 0)
i40e_dev_close(dev);
diff --git a/drivers/net/i40e/i40e_ethdev.h b/drivers/net/i40e/i40e_ethdev.h
index cd67453..9e962eb 100644
--- a/drivers/net/i40e/i40e_ethdev.h
+++ b/drivers/net/i40e/i40e_ethdev.h
@@ -957,6 +957,7 @@ struct i40e_pf {
bool gtp_replace_flag; /* 1 - GTP-C/U filter replace is done */
bool qinq_replace_flag; /* QINQ filter replace is done */
struct i40e_tm_conf tm_conf;
+ struct rte_representor_broker *broker;
/* Dynamic Device Personalization */
bool gtp_support; /* 1 - support GTP-C and GTP-U */
diff --git a/drivers/net/i40e/i40e_prep_ops.c b/drivers/net/i40e/i40e_prep_ops.c
new file mode 100644
index 000..3261b97
--- /dev/null
+++ b/drivers/net/i40e/i40e_prep_ops.c
@@ -0,0 +1,472 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 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
[dpdk-dev] [PATCH 4/6] net/representor: Implement port representor PMD
Representor PMD is a virtual PMD which provides a logical representation in DPDK for ports of a multi port device. This supports configuration, management, and monitoring of VFs of a physical function bound to a userspace control plane application. Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- drivers/net/Makefile | 1 + drivers/net/representor/Makefile | 52 drivers/net/representor/port_representor.c | 323 + .../representor/rte_pmd_representor_version.map| 4 + mk/rte.app.mk | 1 + 5 files changed, 381 insertions(+) create mode 100644 drivers/net/representor/Makefile create mode 100644 drivers/net/representor/port_representor.c create mode 100644 drivers/net/representor/rte_pmd_representor_version.map diff --git a/drivers/net/Makefile b/drivers/net/Makefile index cf33233..3e98cd7 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -71,6 +71,7 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_TAP) += tap DIRS-$(CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD) += thunderx DIRS-$(CONFIG_RTE_LIBRTE_VIRTIO_PMD) += virtio DIRS-$(CONFIG_RTE_LIBRTE_VMXNET3_PMD) += vmxnet3 +DIRS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += representor ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) DIRS-$(CONFIG_RTE_LIBRTE_PMD_KNI) += kni diff --git a/drivers/net/representor/Makefile b/drivers/net/representor/Makefile new file mode 100644 index 000..5647045 --- /dev/null +++ b/drivers/net/representor/Makefile @@ -0,0 +1,52 @@ +# BSD LICENSE +# +# Copyright(c) 2017 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. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_representor.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) +LDLIBS += -lrte_representor + +EXPORT_MAP := rte_pmd_representor_version.map + +LIBABIVER := 1 + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += port_representor.c + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/drivers/net/representor/port_representor.c b/drivers/net/representor/port_representor.c new file mode 100644 index 000..2c934bd --- /dev/null +++ b/drivers/net/representor/port_representor.c @@ -0,0 +1,323 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. 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 PU
[dpdk-dev] [PATCH 3/6] eal: added --enable-representor command line argument in EAL to load representor broker infrastructure
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Declan Doherty
---
lib/librte_eal/bsdapp/eal/eal.c| 6 ++
lib/librte_eal/common/eal_common_options.c | 1 +
lib/librte_eal/common/eal_internal_cfg.h | 2 ++
lib/librte_eal/common/eal_options.h| 2 ++
lib/librte_eal/common/include/rte_eal.h| 8
lib/librte_eal/linuxapp/eal/eal.c | 9 +
6 files changed, 28 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 09112b6..7213fa3 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -779,3 +779,9 @@ int vfio_noiommu_is_enabled(void)
{
return 0;
}
+
+/* return non-zero if port-representor is enabled. */
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 450f266..9369fce 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -78,6 +78,7 @@ const struct option
eal_long_options[] = {
{OPT_BASE_VIRTADDR, 1, NULL, OPT_BASE_VIRTADDR_NUM},
{OPT_CREATE_UIO_DEV,0, NULL, OPT_CREATE_UIO_DEV_NUM },
+ {OPT_ENABLE_REPRESENTOR, 0, NULL, OPT_ENABLE_REPRESENTOR_NUM },
{OPT_FILE_PREFIX, 1, NULL, OPT_FILE_PREFIX_NUM },
{OPT_HELP, 0, NULL, OPT_HELP_NUM },
{OPT_HUGE_DIR, 1, NULL, OPT_HUGE_DIR_NUM },
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index fa6ccbe..55cae8c 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -71,6 +71,8 @@ struct internal_config {
* instead of native TSC */
volatile unsigned no_shconf; /**< true if there is no shared
config */
volatile unsigned create_uio_dev; /**< true to create /dev/uioX devices
*/
+ volatile unsigned enable_representor;
+ /**< true to enable port representor broker for all PFs */
volatile enum rte_proc_type_t process_type; /**< multi-process proc
type */
/** true to try allocating memory on specific sockets */
volatile unsigned force_sockets;
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index 30e6bb4..c2b2162 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -83,6 +83,8 @@ enum {
OPT_VFIO_INTR_NUM,
#define OPT_VMWARE_TSC_MAP"vmware-tsc-map"
OPT_VMWARE_TSC_MAP_NUM,
+#define OPT_ENABLE_REPRESENTOR"enable-representor"
+ OPT_ENABLE_REPRESENTOR_NUM,
OPT_LONG_MAX_NUM
};
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index cc2636c..2f5e68b 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -337,6 +337,14 @@ const char *
rte_eal_mbuf_default_mempool_ops(void);
/**
+ * Get flag for port representor should be enabled or not.
+ *
+ * @return
+ * Returns the enable-representor flag.
+ */
+int rte_representor_enabled(void);
+
+/**
* Run function before main() with low priority.
*
* The constructor will be run after prioritized constructors.
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 017c402..aabd83a 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -613,6 +613,10 @@ eal_parse_args(int argc, char **argv)
internal_config.mbuf_pool_ops_name = optarg;
break;
+ case OPT_ENABLE_REPRESENTOR_NUM:
+ internal_config.enable_representor = 1;
+ break;
+
default:
if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
RTE_LOG(ERR, EAL, "Option %c is not supported "
@@ -1033,3 +1037,8 @@ rte_eal_check_module(const char *module_name)
/* Module has been found */
return 1;
}
+
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
--
2.7.4
[dpdk-dev] [PATCH 1/6] ethdev: added switch_domain and representor port flag
switch_domain attribute has been added to specify that a rte_eth_dev
instance belongs to a switch domain in the software switch.
RTE_ETH_DEV_REPRESENTOR_PORT has been defined to specify that a
rte_eth_dev instance is a representor device.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Declan Doherty
---
lib/librte_ether/rte_ethdev.h | 4
1 file changed, 4 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 18e474d..91794e1 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1047,6 +1047,7 @@ struct rte_eth_dev_info {
/** Configured number of rx/tx queues */
uint16_t nb_rx_queues; /**< Number of RX queues. */
uint16_t nb_tx_queues; /**< Number of TX queues. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
};
/**
@@ -1810,6 +1811,7 @@ struct rte_eth_dev_data {
int numa_node; /**< NUMA node connection */
struct rte_vlan_filter_conf vlan_filter_conf;
/**< VLAN filter configuration. */
+ uint16_t switch_domain; /**< Switch domain which port belongs to. */
};
/** Device supports link state interrupt */
@@ -1818,6 +1820,8 @@ struct rte_eth_dev_data {
#define RTE_ETH_DEV_BONDED_SLAVE 0x0004
/** Device supports device removal interrupt */
#define RTE_ETH_DEV_INTR_RMV 0x0008
+/** Device is a port representor */
+#define RTE_ETH_DEV_REPRESENTOR_PORT 0x0010
/**
* @internal
--
2.7.4
[dpdk-dev] [PATCH 2/6] lib/representor: port representor library to manage broker infrastructure and representor PMDs
The library provides the broker infrastructure to be instantiated by base driver and corresponding methods to manage the broker infrastructure. The broker keeps records of list of representor PMDs. The library also provides methods to manage the representor PMDs by the broker. Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- config/common_base | 5 + lib/Makefile | 3 + lib/librte_representor/Makefile| 53 ++ lib/librte_representor/rte_port_representor.c | 212 + .../rte_port_representor_driver.h | 183 ++ .../rte_port_representor_version.map | 12 ++ mk/rte.app.mk | 1 + 7 files changed, 469 insertions(+) create mode 100644 lib/librte_representor/Makefile create mode 100644 lib/librte_representor/rte_port_representor.c create mode 100644 lib/librte_representor/rte_port_representor_driver.h create mode 100644 lib/librte_representor/rte_port_representor_version.map diff --git a/config/common_base b/config/common_base index 82ee754..06e9d43 100644 --- a/config/common_base +++ b/config/common_base @@ -814,3 +814,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y # Compile the eventdev application # CONFIG_RTE_APP_EVENTDEV=y + +# +# Compile representor PMD +# +CONFIG_RTE_LIBRTE_REPRESENTOR=y diff --git a/lib/Makefile b/lib/Makefile index dc4e8df..b9202ff 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -101,6 +101,9 @@ DEPDIRS-librte_distributor := librte_eal librte_mbuf librte_ether DIRS-$(CONFIG_RTE_LIBRTE_PORT) += librte_port DEPDIRS-librte_port := librte_eal librte_mempool librte_mbuf librte_ether DEPDIRS-librte_port += librte_ip_frag librte_sched +DIRS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += librte_representor +DEPDIRS-librte_representor += librte_ether + ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) DEPDIRS-librte_port += librte_kni endif diff --git a/lib/librte_representor/Makefile b/lib/librte_representor/Makefile new file mode 100644 index 000..09d29f7 --- /dev/null +++ b/lib/librte_representor/Makefile @@ -0,0 +1,53 @@ +# BSD LICENSE +# +# Copyright(c) 2010-2017 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. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_representor.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_port_representor_version.map + +LIBABIVER := 1 + +SRCS-$(CONFIG_RTE_LIBRTE_REPRESENTOR) += rte_port_representor.c + +# +# Export include files +# +SYMLINK-$(CONFIG_RTE_LIBRTE_REPRESENTOR)-include += rte_port_representor_driver.h + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/lib/librte_representor/rte_port_representor.c b/lib/librte_representor/rte_port_representor.c new file mode 100644 index 000..f8debea --- /dev/null +++ b/lib/librte_representor/rte_port_representor.c @@ -0,0 +1,212 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. 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
[dpdk-dev] [RFC 5/5] Enable port representor PMD and broker for ixgbe PMD driver.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/ixgbe/Makefile | 2 +-
drivers/net/ixgbe/ixgbe_ethdev.c | 33 +++--
drivers/net/ixgbe/ixgbe_ethdev.h | 11 ++
drivers/net/ixgbe/ixgbe_prep_ops.c | 279 +
drivers/net/ixgbe/ixgbe_prep_ops.h | 41 ++
5 files changed, 353 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.c
create mode 100644 drivers/net/ixgbe/ixgbe_prep_ops.h
diff --git a/drivers/net/ixgbe/Makefile b/drivers/net/ixgbe/Makefile
index 5e57cb3..f216b97 100644
--- a/drivers/net/ixgbe/Makefile
+++ b/drivers/net/ixgbe/Makefile
@@ -1,7 +1,6 @@
# BSD LICENSE
#
# Copyright(c) 2010-2016 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
@@ -125,6 +124,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_82599_bypass.c
endif
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += rte_pmd_ixgbe.c
SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_IXGBE_PMD) += ixgbe_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_IXGBE_PMD)-include := rte_pmd_ixgbe.h
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index 22171d8..80d5d34 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2,7 +2,6 @@
* BSD LICENSE
*
* Copyright(c) 2010-2017 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
@@ -72,6 +71,7 @@
#include "base/ixgbe_type.h"
#include "base/ixgbe_phy.h"
#include "ixgbe_regs.h"
+#include "ixgbe_prep_ops.h"
/*
* High threshold controlling when to start sending XOFF frames. Must be at
@@ -173,8 +173,6 @@ static void ixgbe_dev_promiscuous_enable(struct rte_eth_dev
*dev);
static void ixgbe_dev_promiscuous_disable(struct rte_eth_dev *dev);
static void ixgbe_dev_allmulticast_enable(struct rte_eth_dev *dev);
static void ixgbe_dev_allmulticast_disable(struct rte_eth_dev *dev);
-static int ixgbe_dev_link_update(struct rte_eth_dev *dev,
- int wait_to_complete);
static void ixgbe_dev_stats_get(struct rte_eth_dev *dev,
struct rte_eth_stats *stats);
static int ixgbe_dev_xstats_get(struct rte_eth_dev *dev,
@@ -205,8 +203,6 @@ static int ixgbe_fw_version_get(struct rte_eth_dev *dev,
char *fw_version,
static void ixgbe_dev_info_get(struct rte_eth_dev *dev,
struct rte_eth_dev_info *dev_info);
static const uint32_t *ixgbe_dev_supported_ptypes_get(struct rte_eth_dev *dev);
-static void ixgbevf_dev_info_get(struct rte_eth_dev *dev,
-struct rte_eth_dev_info *dev_info);
static int ixgbe_dev_mtu_set(struct rte_eth_dev *dev, uint16_t mtu);
static int ixgbe_vlan_filter_set(struct rte_eth_dev *dev,
@@ -267,9 +263,6 @@ static void ixgbevf_dev_stop(struct rte_eth_dev *dev);
static void ixgbevf_dev_close(struct rte_eth_dev *dev);
static void ixgbevf_intr_disable(struct ixgbe_hw *hw);
static void ixgbevf_intr_enable(struct ixgbe_hw *hw);
-static void ixgbevf_dev_stats_get(struct rte_eth_dev *dev,
- struct rte_eth_stats *stats);
-static void ixgbevf_dev_stats_reset(struct rte_eth_dev *dev);
static int ixgbevf_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vlan_id, int on);
static void ixgbevf_vlan_strip_queue_set(struct rte_eth_dev *dev,
@@ -1131,6 +1124,7 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
uint32_t ctrl_ext;
uint16_t csum;
int diag, i;
+ struct rte_port_representor_broker *rep_broker;
PMD_INIT_FUNC_TRACE();
@@ -1248,6 +1242,17 @@ eth_ixgbe_dev_init(struct rte_eth_dev *eth_dev)
return -EIO;
}
+ /* Init port representor broker */
+ if (rte_representor_enabled()) {
+ rep_broker = rte_representor_broker_init(eth_dev,
+ pci_dev->max_vfs, rte_ixgbe_prep_ops);
+ if (rep_broker == NULL) {
+ PMD_INIT_LOG(ERR, "Cannot allocate memory for "
+ "representor broker data\n");
+ return errno;
+ }
+ }
+
/* Reset the hw statistics */
ixgbe_dev_stats_reset(eth_dev);
@@ -1362,6 +1367,10 @@ eth_ixgbe_dev_uninit(struct rte_eth_dev *eth_dev)
hw = IXGBE_DEV_PRIVATE_TO_HW(eth_dev->data->dev_private);
+ /* Deinit port representor broker */
+ if (rte_representor_enabled())
+ rte_representor_broker_free(eth_dev->data->port_id);
+
[dpdk-dev] [RFC 3/5] Implement port representor PMD
Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- config/common_base | 5 + drivers/net/Makefile | 2 + drivers/net/representor/Makefile | 51 ++ drivers/net/representor/rte_eth_representor.c | 973 + .../representor/rte_pmd_representor_version.map| 4 + lib/librte_ether/rte_ethdev_vdev.h | 37 +- mk/rte.app.mk | 1 + 7 files changed, 1070 insertions(+), 3 deletions(-) create mode 100644 drivers/net/representor/Makefile create mode 100644 drivers/net/representor/rte_eth_representor.c create mode 100644 drivers/net/representor/rte_pmd_representor_version.map diff --git a/config/common_base b/config/common_base index 5e97a08..d7ba871 100644 --- a/config/common_base +++ b/config/common_base @@ -750,3 +750,8 @@ CONFIG_RTE_APP_CRYPTO_PERF=y # Compile the eventdev application # CONFIG_RTE_APP_EVENTDEV=y + +# +# Compile representor PMD +# +CONFIG_RTE_LIBRTE_PMD_REPRESENTOR=y diff --git a/drivers/net/Makefile b/drivers/net/Makefile index d33c959..1b76a42 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -83,6 +83,8 @@ DIRS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += pcap DEPDIRS-pcap = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_QEDE_PMD) += qede DEPDIRS-qede = $(core-libs) +DIRS-$(CONFIG_RTE_LIBRTE_PMD_REPRESENTOR) += representor +DEPDIRS-representor = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_PMD_RING) += ring DEPDIRS-ring = $(core-libs) DIRS-$(CONFIG_RTE_LIBRTE_SFC_EFX_PMD) += sfc diff --git a/drivers/net/representor/Makefile b/drivers/net/representor/Makefile new file mode 100644 index 000..18b23f4 --- /dev/null +++ b/drivers/net/representor/Makefile @@ -0,0 +1,51 @@ +# BSD LICENSE +# +# Copyright(c) 2017 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. + +include $(RTE_SDK)/mk/rte.vars.mk + +# +# library name +# +LIB = librte_pmd_representor.a + +CFLAGS += -O3 +CFLAGS += $(WERROR_FLAGS) + +EXPORT_MAP := rte_pmd_representor_version.map + +LIBABIVER := 1 + +# +# all source are stored in SRCS-y +# +SRCS-$(CONFIG_RTE_LIBRTE_PMD_REPRESENTOR) += rte_eth_representor.c + +include $(RTE_SDK)/mk/rte.lib.mk diff --git a/drivers/net/representor/rte_eth_representor.c b/drivers/net/representor/rte_eth_representor.c new file mode 100644 index 000..cec532d --- /dev/null +++ b/drivers/net/representor/rte_eth_representor.c @@ -0,0 +1,973 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2017 Intel Corporation. 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 PROVI
[dpdk-dev] [RFC 4/5] Enable port representor PMD and broker for fortville PMD driver
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
drivers/net/i40e/Makefile| 1 +
drivers/net/i40e/i40e_ethdev.c | 17 ++
drivers/net/i40e/i40e_prep_ops.c | 402 +++
drivers/net/i40e/i40e_prep_ops.h | 41
drivers/net/i40e/rte_pmd_i40e.c | 47 +
drivers/net/i40e/rte_pmd_i40e.h | 18 ++
6 files changed, 526 insertions(+)
create mode 100644 drivers/net/i40e/i40e_prep_ops.c
create mode 100644 drivers/net/i40e/i40e_prep_ops.h
diff --git a/drivers/net/i40e/Makefile b/drivers/net/i40e/Makefile
index 55c79a6..a299a1e 100644
--- a/drivers/net/i40e/Makefile
+++ b/drivers/net/i40e/Makefile
@@ -110,6 +110,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_fdir.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_flow.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += rte_pmd_i40e.c
SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_tm.c
+SRCS-$(CONFIG_RTE_LIBRTE_I40E_PMD) += i40e_prep_ops.c
# install this header file
SYMLINK-$(CONFIG_RTE_LIBRTE_I40E_PMD)-include := rte_pmd_i40e.h
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5f26e24..942a587 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -65,6 +65,7 @@
#include "i40e_rxtx.h"
#include "i40e_pf.h"
#include "i40e_regs.h"
+#include "i40e_prep_ops.h"
#define ETH_I40E_FLOATING_VEB_ARG "enable_floating_veb"
#define ETH_I40E_FLOATING_VEB_LIST_ARG "floating_veb_list"
@@ -1045,6 +1046,7 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
int ret;
uint32_t len;
uint8_t aq_fail = 0;
+ struct rte_port_representor_broker *rb;
PMD_INIT_FUNC_TRACE();
@@ -1088,6 +1090,17 @@ eth_i40e_dev_init(struct rte_eth_dev *dev)
hw->bus.func = pci_dev->addr.function;
hw->adapter_stopped = 0;
+ /* init representor broker */
+ if (rte_representor_enabled()) {
+ rb = rte_representor_broker_init(dev, pci_dev->max_vfs,
+ rte_i40e_prep_ops);
+ if (rb == NULL) {
+ PMD_INIT_LOG(ERR, "Cannot allocate memory for "
+ "representor broker data\n");
+ return errno;
+ }
+ }
+
/* Make sure all is clean before doing PF reset */
i40e_clear_hw(hw);
@@ -2130,6 +2143,10 @@ i40e_dev_close(struct rte_eth_dev *dev)
PMD_INIT_FUNC_TRACE();
+ /* free port representor pmds */
+ if (rte_representor_enabled())
+ rte_representor_broker_free(dev->data->port_id);
+
i40e_dev_stop(dev);
i40e_dev_free_queues(dev);
diff --git a/drivers/net/i40e/i40e_prep_ops.c b/drivers/net/i40e/i40e_prep_ops.c
new file mode 100644
index 000..15aaeb3
--- /dev/null
+++ b/drivers/net/i40e/i40e_prep_ops.c
@@ -0,0 +1,402 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2017 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.
+ */
+
+#include
+#include
+
+#include "base/i40e_type.h"
+#include "base/virtchnl.h"
+#include "i40e_ethdev.h"
+#include "i40e_rxtx.h"
+#include "rte_pmd_i40e.h"
+
+#include "i40e_prep_ops.h"
+
+static int i40e_prep_link_up
[dpdk-dev] [RFC 2/5] added --enable-representor command line argument in EAL to load representor broker infrastructure.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
lib/librte_eal/bsdapp/eal/eal.c| 6 ++
lib/librte_eal/common/eal_common_options.c | 1 +
lib/librte_eal/common/eal_internal_cfg.h | 2 ++
lib/librte_eal/common/eal_options.h| 2 ++
lib/librte_eal/common/include/rte_eal.h| 8
lib/librte_eal/linuxapp/eal/eal.c | 9 +
6 files changed, 28 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 5fa5988..d1a3c79 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -698,3 +698,9 @@ rte_eal_process_type(void)
{
return rte_config.process_type;
}
+
+/* return non-zero if port-representor is enabled. */
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 1da185e..f9c0b42 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -78,6 +78,7 @@ const struct option
eal_long_options[] = {
{OPT_BASE_VIRTADDR, 1, NULL, OPT_BASE_VIRTADDR_NUM},
{OPT_CREATE_UIO_DEV,0, NULL, OPT_CREATE_UIO_DEV_NUM },
+ {OPT_ENABLE_REPRESENTOR, 0, NULL, OPT_ENABLE_REPRESENTOR_NUM },
{OPT_FILE_PREFIX, 1, NULL, OPT_FILE_PREFIX_NUM },
{OPT_HELP, 0, NULL, OPT_HELP_NUM },
{OPT_HUGE_DIR, 1, NULL, OPT_HUGE_DIR_NUM },
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 7b7e8c8..d0b3080 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -72,6 +72,8 @@ struct internal_config {
* instead of native TSC */
volatile unsigned no_shconf; /**< true if there is no shared
config */
volatile unsigned create_uio_dev; /**< true to create /dev/uioX devices
*/
+ volatile unsigned enable_representor;
+ /**< true to enable port representor broker for all PFs */
volatile enum rte_proc_type_t process_type; /**< multi-process proc
type */
/** true to try allocating memory on specific sockets */
volatile unsigned force_sockets;
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index 439a261..a8be6e3 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -49,6 +49,8 @@ enum {
OPT_BASE_VIRTADDR_NUM,
#define OPT_CREATE_UIO_DEV"create-uio-dev"
OPT_CREATE_UIO_DEV_NUM,
+#define OPT_ENABLE_REPRESENTOR"enable-representor"
+ OPT_ENABLE_REPRESENTOR_NUM,
#define OPT_FILE_PREFIX "file-prefix"
OPT_FILE_PREFIX_NUM,
#define OPT_HUGE_DIR "huge-dir"
diff --git a/lib/librte_eal/common/include/rte_eal.h
b/lib/librte_eal/common/include/rte_eal.h
index 0e7363d..4d4a6ce 100644
--- a/lib/librte_eal/common/include/rte_eal.h
+++ b/lib/librte_eal/common/include/rte_eal.h
@@ -287,6 +287,14 @@ static inline int rte_gettid(void)
return RTE_PER_LCORE(_thread_id);
}
+/**
+ * Get flag for port representor should be enabled or not.
+ *
+ * @return
+ * Returns the enable-representor flag.
+ */
+int rte_representor_enabled(void);
+
#define RTE_INIT(func) \
static void __attribute__((constructor, used)) func(void)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 48f12f4..165da30 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -610,6 +610,10 @@ eal_parse_args(int argc, char **argv)
internal_config.create_uio_dev = 1;
break;
+ case OPT_ENABLE_REPRESENTOR_NUM:
+ internal_config.enable_representor = 1;
+ break;
+
default:
if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
RTE_LOG(ERR, EAL, "Option %c is not supported "
@@ -1016,3 +1020,8 @@ rte_eal_check_module(const char *module_name)
/* Module has been found */
return 1;
}
+
+int rte_representor_enabled(void)
+{
+ return internal_config.enable_representor;
+}
--
2.7.4
[dpdk-dev] [RFC 1/5] Implemented port representor broker infrastructure, created BDF to port function.
Signed-off-by: Mohammad Abdul Awal
Signed-off-by: Remy Horton
Signed-off-by: Declan Doherty
---
lib/librte_ether/Makefile | 2 +
lib/librte_ether/rte_ethdev.c | 93 ++
lib/librte_ether/rte_ethdev.h | 26 +++
lib/librte_ether/rte_ether_version.map | 9 +
lib/librte_ether/rte_port_representor.c | 160 ++
lib/librte_ether/rte_port_representor.h | 289
6 files changed, 579 insertions(+)
create mode 100644 lib/librte_ether/rte_port_representor.c
create mode 100644 lib/librte_ether/rte_port_representor.h
diff --git a/lib/librte_ether/Makefile b/lib/librte_ether/Makefile
index db692ae..b61a84b 100644
--- a/lib/librte_ether/Makefile
+++ b/lib/librte_ether/Makefile
@@ -46,6 +46,7 @@ LIBABIVER := 6
SRCS-y += rte_ethdev.c
SRCS-y += rte_flow.c
SRCS-y += rte_tm.c
+SRCS-y += rte_port_representor.c
#
# Export include files
@@ -59,5 +60,6 @@ SYMLINK-y-include += rte_flow.h
SYMLINK-y-include += rte_flow_driver.h
SYMLINK-y-include += rte_tm.h
SYMLINK-y-include += rte_tm_driver.h
+SYMLINK-y-include += rte_port_representor.h
include $(RTE_SDK)/mk/rte.lib.mk
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0597641..3bca00f 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -67,6 +67,7 @@
#include "rte_ether.h"
#include "rte_ethdev.h"
+#include "rte_port_representor.h"
static const char *MZ_RTE_ETH_DEV_DATA = "rte_eth_dev_data";
struct rte_eth_dev rte_eth_devices[RTE_MAX_ETHPORTS];
@@ -360,6 +361,98 @@ rte_eth_dev_get_port_by_name(const char *name, uint8_t
*port_id)
return -ENODEV;
}
+#define RTE_ETH_EBDF_MAX_COLONS 2
+#define RTE_ETH_EBDF_MAX_PERIODS 1
+
+static inline int
+char_to_value(char value)
+{
+ if (value >= '0' && value <= '9')
+ return value - '0';
+ if (value >= 'A' && value <= 'F')
+ return value - 'A' + 10;
+ if (value >= 'a' && value <= 'f')
+ return value - 'a' + 10;
+ return -1;
+}
+
+static int
+parse_ebdf_addr(const char * const addr_str, struct rte_pci_addr *pci_addr)
+{
+ const char *str_pos;
+
+ int cnt_colons = 0;
+ int cnt_periods = 0;
+ int nibbles[RTE_ETH_EBDF_MAX_COLONS + RTE_ETH_EBDF_MAX_PERIODS + 1];
+ int param_value;
+ int digit_value;
+
+ str_pos = addr_str;
+ param_value = 0;
+ while (*str_pos) {
+ if (isxdigit(*str_pos)) {
+ digit_value = char_to_value(*str_pos);
+ if (digit_value == -1)
+ return -EINVAL;
+ param_value = (param_value << 4) | digit_value;
+ } else if (*str_pos == ':') {
+ if (cnt_periods != 0 ||
+ cnt_colons >= RTE_ETH_EBDF_MAX_COLONS)
+ return -EINVAL;
+ nibbles[cnt_colons++] = param_value;
+ param_value = 0;
+ } else if (*str_pos == '.') {
+ if (cnt_periods >= RTE_ETH_EBDF_MAX_PERIODS)
+ return -EINVAL;
+ nibbles[cnt_colons + cnt_periods] = param_value;
+ param_value = 0;
+ cnt_periods++;
+ } else
+ return -EINVAL;
+ str_pos++;
+ }
+ nibbles[cnt_colons + cnt_periods] = param_value;
+
+ if (cnt_colons == 2 && cnt_periods == 1) {
+ pci_addr->domain = nibbles[0];
+ pci_addr->bus = nibbles[1];
+ pci_addr->devid = nibbles[2];
+ pci_addr->function = nibbles[3];
+ } else if (cnt_colons == 1 && cnt_periods == 1) {
+ pci_addr->domain = 0;
+ pci_addr->bus = nibbles[0];
+ pci_addr->devid = nibbles[1];
+ pci_addr->function = nibbles[2];
+ } else
+ return -EINVAL;
+
+ return 0;
+}
+
+int
+rte_eth_dev_get_port_by_pci_addr_str(const char *pci_str, uint8_t *port_id)
+{
+ struct rte_pci_device *pci_dev;
+ struct rte_pci_addr pci_addr;
+
+ if (parse_ebdf_addr(pci_str, &pci_addr) != 0)
+ return -EINVAL;
+
+ FOREACH_DEVICE_ON_PCIBUS(pci_dev) {
+ if (pci_dev->driver == NULL) {
+ /* No loaded driver - skip */
+ continue;
+ }
+ if (rte_eal_compare_pci_addr(&pci_addr, &pci_dev->addr) == 0) {
+ /* (E)BDF resolved to device name. Now get port_id..
+*/
+
[dpdk-dev] [RFC 0/5] Port Representor for control and monitoring of VF devices
Signed-off-by: Mohammad Abdul Awal Signed-off-by: Remy Horton Signed-off-by: Declan Doherty --- This RFC introduces a port representor based model for the control, management and monitoring of SR-IOV virtual function (VF) devices for control plane applications which have bound the devices physical function. Port Representors are virtual poll mode drivers (PMD) which provide a logical representation in DPDK for VF ports for control and monitoring. Each port representor PMD represents a single VF and is associated with it's parent physical function (PF) PMD which provides the back-end hooks for the representor device ops and defines the control domain to which that port belongs.This allows to use existing DPDK APIs to monitor and control the port without the need to create and maintain VF specific APIs. +-+ +---+ +---+ |Control Plane| | Data Plane | | Data Plane | | Application | | Application | | Application | +-+ +---+ +---+ | eth dev api | | eth dev api | | eth dev api | +-+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | PF0 | | Port | | Port | |VF0 PMD| |VF0 PMD| | PMD <--+ Rep 0 | | Rep 1 | +---+ +--++ | | | PMD | | PMD | | +---+--^+ +---+ +-+-+ | | || || | ++ || | || | || ++ | | | HW (logical view) | | | | --+--+ +---+ +---+---+ | | | | PF | | VF0 | | VF1 | | | | || | | | ++ | ++ +---+ +---+ | | ++ | | |VEB | | | ++ | | ++ | | | Port | | | | 0| | | ++ | ++ The figure above shows a deployment where the PF is bound to a DPDK control plane application which uses representor ports to manage the configuration and monitoring of it's VF ports. Each virtual function is represented in the application by a representor port PMD which enables control of the corresponding VF through eth dev APIs on the representor PMD such as: - void rte_eth_promiscuous_enable(uint8_t port_id); - void rte_eth_promiscuous_disable(uint8_t port_id); - void rte_eth_allmulticast_enable(uint8_t port_id); - void rte_eth_allmulticast_disable(uint8_t port_id); - int rte_eth_dev_mac_addr_add(uint8_t port, struct ether_addr *mac_addr, uint32_t pool); - int rte_eth_dev_set_vlan_offload(uint8_t port_id, int offload_mask); as well as monitoring through API's like - void rte_eth_link_get(uint8_t port_id, struct rte_eth_link *link); - int rte_eth_stats_get(uint8_t port_id, struct rte_eth_stats *stats); The port representor infrastructure is enabled through a single common, device independent, virtual PMD whos context is initialized and enabled through a broker instance running within the context of the physical function device driver. +-+ +-+ |rte_ethdev | | rte_ethdev| +-+ +-+ | Physical Function PMD | | Port Reperesentor PMD | | +-+ | | +-+ +-+ | | | Representor | | | | dev_data| | dev_ops | | | |Broker | | | +++ +++ | | | +-+ | | +--|---|--+ | | | VF Port | | | | | | | | Context +--+ | | | +-+ | | | | | +-+ | | | | | | Handler +--+ | | | Ops | | | | | +-+ | | | +-+ | +-+ Creation of representor ports can be achieved either through the --vdev EAL option or through the rte_vdev_init() API. Each port representor requires the BDF of it's parent PF and the Virtual Function ID of the port which the representor will support. During initialization of the representor PMD, it calls the broker API to register itself with the PF PMD and to get it's context configured which includes the setting up of it's context and ops
[dpdk-dev] [PATCH v2] app/testpmd: fix RSS-hash-key size
RSS hash-key-size is retrieved from device configuration instead of
using a fixed size of 40 bytes.
Fixes: f79959ea1504 ("app/testpmd: allow to configure RSS hash key")
Signed-off-by: Mohammad Abdul Awal
---
v2:
* Used macro instead of hard-coded value.
* Some nits as per comments.
app/test-pmd/cmdline.c | 27 ---
app/test-pmd/config.c | 18 +++---
app/test-pmd/testpmd.h | 6 ++
3 files changed, 41 insertions(+), 10 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f90befc..a631c43 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1608,7 +1608,6 @@ struct cmd_config_rss_hash_key {
cmdline_fixed_string_t key;
};
-#define RSS_HASH_KEY_LENGTH 40
static uint8_t
hexa_digit_to_value(char hexa_digit)
{
@@ -1644,16 +1643,29 @@ cmd_config_rss_hash_key_parsed(void *parsed_result,
uint8_t xdgt0;
uint8_t xdgt1;
int i;
+ struct rte_eth_dev_info dev_info;
+ uint8_t hash_key_size;
+ uint32_t key_len;
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(res->port_id, &dev_info);
+ if (dev_info.hash_key_size > 0 &&
+ dev_info.hash_key_size <= sizeof(hash_key))
+ hash_key_size = dev_info.hash_key_size;
+ else {
+ printf("dev_info did not provide a valid hash key size\n");
+ return;
+ }
/* Check the length of the RSS hash key */
- if (strlen(res->key) != (RSS_HASH_KEY_LENGTH * 2)) {
+ key_len = strlen(res->key);
+ if (key_len != (hash_key_size * 2)) {
printf("key length: %d invalid - key must be a string of %d"
- "hexa-decimal numbers\n", (int) strlen(res->key),
- RSS_HASH_KEY_LENGTH * 2);
+ " hexa-decimal numbers\n",
+ (int) key_len, hash_key_size * 2);
return;
}
/* Translate RSS hash key into binary representation */
- for (i = 0; i < RSS_HASH_KEY_LENGTH; i++) {
+ for (i = 0; i < hash_key_size; i++) {
xdgt0 = parse_and_check_key_hexa_digit(res->key, (i * 2));
if (xdgt0 == 0xFF)
return;
@@ -1663,7 +1675,7 @@ cmd_config_rss_hash_key_parsed(void *parsed_result,
hash_key[i] = (uint8_t) ((xdgt0 * 16) + xdgt1);
}
port_rss_hash_key_update(res->port_id, res->rss_type, hash_key,
-RSS_HASH_KEY_LENGTH);
+ hash_key_size);
}
cmdline_parse_token_string_t cmd_config_rss_hash_key_port =
@@ -1692,7 +1704,8 @@ cmdline_parse_inst_t cmd_config_rss_hash_key = {
"port config X rss-hash-key ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|"
"ipv4-sctp|ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|"
"ipv6-sctp|ipv6-other|l2-payload|"
- "ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex 80 hexa digits\n",
+ "ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex "
+ "\n",
.tokens = {
(void *)&cmd_config_rss_hash_key_port,
(void *)&cmd_config_rss_hash_key_config,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index bfcbff9..44ba91e 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1012,14 +1012,26 @@ void
port_rss_hash_conf_show(portid_t port_id, char rss_info[], int show_rss_key)
{
struct rte_eth_rss_conf rss_conf;
- uint8_t rss_key[10 * 4] = "";
+ uint8_t rss_key[RSS_HASH_KEY_LENGTH];
uint64_t rss_hf;
uint8_t i;
int diag;
+ struct rte_eth_dev_info dev_info;
+ uint8_t hash_key_size;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (dev_info.hash_key_size > 0 &&
+ dev_info.hash_key_size <= sizeof(rss_key))
+ hash_key_size = dev_info.hash_key_size;
+ else {
+ printf("dev_info did not provide a valid hash key size\n");
+ return;
+ }
+
rss_conf.rss_hf = 0;
for (i = 0; i < RTE_DIM(rss_type_table); i++) {
if (!strcmp(rss_info, rss_type_table[i].str))
@@ -1028,7 +1040,7 @@ port_rss_hash_conf_show(portid_t port_id, char
rss_info[], int show_rss_key)
/* Get RSS hash key if asked to display it */
rss_conf.rss_key = (show_rss_key) ? rss_key : NULL;
- rss_conf.rss_key_len = sizeof(rss_key);
+ rss_conf.rss_key_len = hash_key_size;
diag = rte_eth_dev_rss_hash_conf_get(port_id, &rss_conf);
if (diag != 0) {
switch (dia
[dpdk-dev] [PATCH] app/testpmd: fix RSS-hash-key size
RSS hash-key-size is retrieved from device configuration instead of
using a fixed size of 40 bytes.
Fixes: f79959ea1504 ("app/testpmd: allow to configure RSS hash key")
Signed-off-by: Mohammad Abdul Awal
---
app/test-pmd/cmdline.c | 24 +---
app/test-pmd/config.c | 17 ++---
2 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index f90befc..14412b4 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1608,7 +1608,6 @@ struct cmd_config_rss_hash_key {
cmdline_fixed_string_t key;
};
-#define RSS_HASH_KEY_LENGTH 40
static uint8_t
hexa_digit_to_value(char hexa_digit)
{
@@ -1640,20 +1639,30 @@ cmd_config_rss_hash_key_parsed(void *parsed_result,
__attribute__((unused)) void *data)
{
struct cmd_config_rss_hash_key *res = parsed_result;
- uint8_t hash_key[RSS_HASH_KEY_LENGTH];
+ uint8_t hash_key[16 * 4];
uint8_t xdgt0;
uint8_t xdgt1;
int i;
+ struct rte_eth_dev_info dev_info;
+ uint8_t hash_key_size;
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(res->port_id, &dev_info);
+ if (dev_info.hash_key_size > 0) {
+ hash_key_size = dev_info.hash_key_size;
+ } else {
+ printf("dev_info did not provide a valid hash key size\n");
+ return;
+ }
/* Check the length of the RSS hash key */
- if (strlen(res->key) != (RSS_HASH_KEY_LENGTH * 2)) {
+ if (strlen(res->key) != (hash_key_size * 2)) {
printf("key length: %d invalid - key must be a string of %d"
"hexa-decimal numbers\n", (int) strlen(res->key),
- RSS_HASH_KEY_LENGTH * 2);
+ hash_key_size * 2);
return;
}
/* Translate RSS hash key into binary representation */
- for (i = 0; i < RSS_HASH_KEY_LENGTH; i++) {
+ for (i = 0; i < hash_key_size; i++) {
xdgt0 = parse_and_check_key_hexa_digit(res->key, (i * 2));
if (xdgt0 == 0xFF)
return;
@@ -1663,7 +1672,7 @@ cmd_config_rss_hash_key_parsed(void *parsed_result,
hash_key[i] = (uint8_t) ((xdgt0 * 16) + xdgt1);
}
port_rss_hash_key_update(res->port_id, res->rss_type, hash_key,
-RSS_HASH_KEY_LENGTH);
+ hash_key_size);
}
cmdline_parse_token_string_t cmd_config_rss_hash_key_port =
@@ -1692,7 +1701,8 @@ cmdline_parse_inst_t cmd_config_rss_hash_key = {
"port config X rss-hash-key ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|"
"ipv4-sctp|ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|"
"ipv6-sctp|ipv6-other|l2-payload|"
- "ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex 80 hexa digits\n",
+ "ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex "
+ "80 hexa digits (104 hexa digits for fortville)\n",
.tokens = {
(void *)&cmd_config_rss_hash_key_port,
(void *)&cmd_config_rss_hash_key_config,
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index bfcbff9..851408b 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -1012,14 +1012,25 @@ void
port_rss_hash_conf_show(portid_t port_id, char rss_info[], int show_rss_key)
{
struct rte_eth_rss_conf rss_conf;
- uint8_t rss_key[10 * 4] = "";
+ uint8_t rss_key[16 * 4] = "";
uint64_t rss_hf;
uint8_t i;
int diag;
+ struct rte_eth_dev_info dev_info;
+ uint8_t hash_key_size;
if (port_id_is_invalid(port_id, ENABLED_WARN))
return;
+ memset(&dev_info, 0, sizeof(dev_info));
+ rte_eth_dev_info_get(port_id, &dev_info);
+ if (dev_info.hash_key_size > 0) {
+ hash_key_size = dev_info.hash_key_size;
+ } else {
+ printf("dev_info did not provide a valid hash key size\n");
+ return;
+ }
+
rss_conf.rss_hf = 0;
for (i = 0; i < RTE_DIM(rss_type_table); i++) {
if (!strcmp(rss_info, rss_type_table[i].str))
@@ -1028,7 +1039,7 @@ port_rss_hash_conf_show(portid_t port_id, char
rss_info[], int show_rss_key)
/* Get RSS hash key if asked to display it */
rss_conf.rss_key = (show_rss_key) ? rss_key : NULL;
- rss_conf.rss_key_len = sizeof(rss_key);
+ rss_conf.rss_key_len = hash_key_size;
diag = rte_eth_dev_rss_hash_conf_get(port_id, &rss_conf);
if (diag != 0) {
switch (diag) {
@@ -1058,7 +1069,7 @@ port_rss_hash_conf_show(portid_t port_id, char
rss_info[], int show_rss_key)
if (!show_rss_key)
