[dpdk-dev] [PATCH] remove redundant __func__ in PMD_INIT_LOG and PMD_RX_LOG
Acked-by: Yuanhan Liu --yliu
[dpdk-dev] [PATCH] pci: Add the class_id support in pci probe
This patch is used to add the class_id support
for pci_probe since some devices need the class_info
(class_code, subclass_code, programming_interface)
Signed-off-by: Ziye Yang
---
lib/librte_eal/bsdapp/eal/eal_pci.c | 4
lib/librte_eal/common/eal_common_pci.c | 3 +++
lib/librte_eal/common/include/rte_pci.h | 8 ++--
lib/librte_eal/linuxapp/eal/eal_pci.c | 9 +
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 6c21fbd..3b12ee6 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -273,6 +273,10 @@ pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
/* get subsystem_device id */
dev->id.subsystem_device_id = conf->pc_subdevice;
+ dev->id.class_id = (conf->pc_class << 16) |
+ (conf->pc_subclass << 8) |
+ (conf->pc_progif);
+
/* TODO: get max_vfs */
dev->max_vfs = 0;
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index dcfe947..6832821 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -162,6 +162,9 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *d
if (id_table->subsystem_device_id !=
dev->id.subsystem_device_id &&
id_table->subsystem_device_id != PCI_ANY_ID)
continue;
+ if (id_table->class_id != dev->id.class_id &&
+ id_table->class_id != CLASS_ANY_ID)
+ continue;
struct rte_pci_addr *loc = &dev->addr;
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 334c12e..a538fbe 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -129,6 +129,7 @@ struct rte_pci_id {
uint16_t device_id; /**< Device ID or PCI_ANY_ID. */
uint16_t subsystem_vendor_id; /**< Subsystem vendor ID or PCI_ANY_ID. */
uint16_t subsystem_device_id; /**< Subsystem device ID or PCI_ANY_ID. */
+ uint32_t class_id; /**< Class ID (class, subclass, pi) or
CLASS_ANY_ID. */
};
/**
@@ -170,6 +171,7 @@ struct rte_pci_device {
/** Any PCI device identifier (vendor, device, ...) */
#define PCI_ANY_ID (0x)
+#define CLASS_ANY_ID (0xff)
#ifdef __cplusplus
/** C++ macro used to help building up tables of device IDs */
@@ -177,14 +179,16 @@ struct rte_pci_device {
(vend), \
(dev),\
PCI_ANY_ID, \
- PCI_ANY_ID
+ PCI_ANY_ID, \
+ CLASS_ANY_ID
#else
/** Macro used to help building up tables of device IDs */
#define RTE_PCI_DEVICE(vend, dev) \
.vendor_id = (vend), \
.device_id = (dev),\
.subsystem_vendor_id = PCI_ANY_ID, \
- .subsystem_device_id = PCI_ANY_ID
+ .subsystem_device_id = PCI_ANY_ID, \
+ .class_id = CLASS_ANY_ID
#endif
struct rte_pci_driver;
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index bc5b5be..d9bfc0c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -306,6 +306,15 @@ pci_scan_one(const char *dirname, uint16_t domain, uint8_t
bus,
}
dev->id.subsystem_device_id = (uint16_t)tmp;
+ /* get class_id */
+ snprintf(filename, sizeof(filename), "%s/class",
+dirname);
+ if (eal_parse_sysfs_value(filename, &tmp) < 0) {
+ free(dev);
+ return -1;
+ }
+ dev->id.class_id = (uint32_t)tmp && CLASS_ANY_ID;
+
/* get max_vfs */
dev->max_vfs = 0;
snprintf(filename, sizeof(filename), "%s/max_vfs", dirname);
--
1.9.3
[dpdk-dev] Is there an interrupt mode PMD for virtio
Hi, I am asking if there is an interrupt mode PMD for virtio driver. I check with l3fwd-power code, it is based on VFIO driver. However, it seems that current virtio driver does not support VFIO. Thanks. HePeng
[dpdk-dev] Is there an interrupt mode PMD for virtio
Hi, I am asking if there is an interrupt mode PMD for virtio driver. I check with l3fwd-power code, it is based on VFIO driver. However, it seems that current virtio driver does not support VFIO. Thanks. HePeng
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla wrote: > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu > wrote: >> On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla wrote: >>> >> I guess we have done enough evaluation / investigation that suggest - >>> >> so to map iopci region to userspace in arch agnostic-way - >>> >> >>> >> # either we need to modify kernel >>> >>- Make sure all the non-x86 arch to support mapping for >>> >> iopci region (i.e. pci_mmap_page_range). I don;t think its a correct >>> >> approach though. >>> >> or >>> >>- include /dev/ioport char-mem device file who could do >>> >> more than byte operation, Note that this implementation does not exist >>> >> in kernel. I could send an RFC to lkml. >>> > >>> > Maybe you could propose the two to lkml, to get some feedbacks from >>> > those kernel/ARM gurus? Please cc me if you do so. >>> > >>> >>> The latter one I already shared old lkml thread, Pl. revisit my v1 0/6 >>> patch [1] and in that refer [2]. >> >> Oops, sorry, a bit busy, that I didn't look at it carefully. My bad, >> anyway. >> >>> Josh has already proposed to lkml but for some reason thread didn't >>> went far. I can restart that discussion giving dpdk use-case as an >>> example/ requirement. >> >> I had a quick go through of the discussion. Both hpa and Arnd seem >> to be fine with the ioctl interface on /dev/port. Have you tried >> that? And if you want to restart it, ioctl might be a better option >> than /dev/ioport, judging from the discussion. >> > > I tried legacy patch and re-writing with ioctl-way; doing changes in > dpdk port as well in kernel, had to test on quite other hw not only > arm64 though! so it will take time for me, I am travelling tomorrow so > bit delayed, We'll post patch to lkml and share dpdk-virtio feedback > perhaps by Monday. > I posted a query about /dev/ioports approach in lkml thread [1], and Arnd suggested to use vfio framework but it looks like vfio too does not map ioresource_io region. Same communicated to Arnd and waiting for his reply. In mean time I like to ask general question; - Has anyone tried vfio/non-iommu approach for virtio pmd driver? If not then Is there any plan? Someone planning to take up. [1] https://lkml.org/lkml/2015/12/23/145
[dpdk-dev] bnx2x pmd performance expectations
Thank you for pointing this out. While it seems to me problem here is RX, I will also look into TX burst limitations. -a On 28 December 2015 at 00:17, Chas Williams <3chas3 at gmail.com> wrote: > I wouldn't consider myself an expert on this driver but while looking > at some other things, I have noted that RTE_PMD_BNX2X_TX_MAX_BURST is > defined to be 1. This bursts single packets to bnx2x_tx_encap() but it > looks like bnx2x_tx_encap() is far more capable than that. > > On Tue, 2015-12-22 at 14:52 +0300, Alexander Belyakov wrote: > > Hi, > > > > just tried to forward a lot of tiny packets with testpmd (dpdk-2.2.0) > > running on Broadcom Corporation NetXtreme II BCM57810S 10 Gigabit > > Ethernet > > (rev 10) adapter. I see forwarding performance of 2.6Mpps instead of > > expected 14.8Mpps. What should be done to achieve better results? > > > > Thank you, > > Alexander Belyakov >
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
Hi Santosh, > On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla > wrote: > > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu > > wrote: > >> On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla wrote: > >>> >> I guess we have done enough evaluation / investigation that > >>> >> suggest - so to map iopci region to userspace in arch > >>> >> agnostic-way - > >>> >> > >>> >> # either we need to modify kernel > >>> >>- Make sure all the non-x86 arch to support > >>> >> mapping for iopci region (i.e. pci_mmap_page_range). I don;t > >>> >> think its a correct approach though. > >>> >> or > >>> >>- include /dev/ioport char-mem device file who > >>> >> could do more than byte operation, Note that this implementation > >>> >> does not exist in kernel. I could send an RFC to lkml. > >>> > > >>> > Maybe you could propose the two to lkml, to get some feedbacks > >>> > from those kernel/ARM gurus? Please cc me if you do so. > >>> > > >>> > >>> The latter one I already shared old lkml thread, Pl. revisit my v1 > >>> 0/6 patch [1] and in that refer [2]. > >> > >> Oops, sorry, a bit busy, that I didn't look at it carefully. My bad, > >> anyway. > >> > >>> Josh has already proposed to lkml but for some reason thread didn't > >>> went far. I can restart that discussion giving dpdk use-case as an > >>> example/ requirement. > >> > >> I had a quick go through of the discussion. Both hpa and Arnd seem to > >> be fine with the ioctl interface on /dev/port. Have you tried that? > >> And if you want to restart it, ioctl might be a better option than > >> /dev/ioport, judging from the discussion. > >> > > > > I tried legacy patch and re-writing with ioctl-way; doing changes in > > dpdk port as well in kernel, had to test on quite other hw not only > > arm64 though! so it will take time for me, I am travelling tomorrow so > > bit delayed, We'll post patch to lkml and share dpdk-virtio feedback > > perhaps by Monday. > > > > I posted a query about /dev/ioports approach in lkml thread [1], and Arnd > suggested to use vfio framework but it looks like vfio too does not map > ioresource_io region. Same communicated to Arnd and waiting for his reply. > > In mean time I like to ask general question; > - Has anyone tried vfio/non-iommu approach for virtio pmd driver? If not > then Is there any plan? Someone planning to take up. > [1] https://lkml.org/lkml/2015/12/23/145 I have submitted a patch to support no-iommu mode, but I'm not aware of anyone trying VFIO-noiommu at all. That's probably expected since it's Christmas/New Year in a lot of places, and everyone is on a break. That said, I'm not sure I completely understand what is it that you're asking about. The code you're referring to (in vfio_pci.c, line 854 as of kernel 4.3) is checking if a PCI BAR is available for IO (hence checking if the IORESOURCE_MEM bit is set). There isn't any "ioresource_mem" region as far as VFIO is concerned, there are only BARs, ROM, VGA and PCI config regions (linux/vfio.h, line 314 as of kernel 4.3). So if you're missing some PCI regions for VFIO to map, they would first need to be added to VFIO kernel implementation before they can be used by DPDK. That is, unless I'm misunderstanding something :) Thanks, Anatoly
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
On Tue, Dec 29, 2015 at 3:26 PM, Burakov, Anatoly wrote: > Hi Santosh, > >> On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla >> wrote: >> > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu >> > wrote: >> >> On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla wrote: >> >>> >> I guess we have done enough evaluation / investigation that >> >>> >> suggest - so to map iopci region to userspace in arch >> >>> >> agnostic-way - >> >>> >> >> >>> >> # either we need to modify kernel >> >>> >>- Make sure all the non-x86 arch to support >> >>> >> mapping for iopci region (i.e. pci_mmap_page_range). I don;t >> >>> >> think its a correct approach though. >> >>> >> or >> >>> >>- include /dev/ioport char-mem device file who >> >>> >> could do more than byte operation, Note that this implementation >> >>> >> does not exist in kernel. I could send an RFC to lkml. >> >>> > >> >>> > Maybe you could propose the two to lkml, to get some feedbacks >> >>> > from those kernel/ARM gurus? Please cc me if you do so. >> >>> > >> >>> >> >>> The latter one I already shared old lkml thread, Pl. revisit my v1 >> >>> 0/6 patch [1] and in that refer [2]. >> >> >> >> Oops, sorry, a bit busy, that I didn't look at it carefully. My bad, >> >> anyway. >> >> >> >>> Josh has already proposed to lkml but for some reason thread didn't >> >>> went far. I can restart that discussion giving dpdk use-case as an >> >>> example/ requirement. >> >> >> >> I had a quick go through of the discussion. Both hpa and Arnd seem to >> >> be fine with the ioctl interface on /dev/port. Have you tried that? >> >> And if you want to restart it, ioctl might be a better option than >> >> /dev/ioport, judging from the discussion. >> >> >> > >> > I tried legacy patch and re-writing with ioctl-way; doing changes in >> > dpdk port as well in kernel, had to test on quite other hw not only >> > arm64 though! so it will take time for me, I am travelling tomorrow so >> > bit delayed, We'll post patch to lkml and share dpdk-virtio feedback >> > perhaps by Monday. >> > >> >> I posted a query about /dev/ioports approach in lkml thread [1], and Arnd >> suggested to use vfio framework but it looks like vfio too does not map >> ioresource_io region. Same communicated to Arnd and waiting for his reply. >> >> In mean time I like to ask general question; >> - Has anyone tried vfio/non-iommu approach for virtio pmd driver? If not >> then Is there any plan? Someone planning to take up. >> [1] https://lkml.org/lkml/2015/12/23/145 > > I have submitted a patch to support no-iommu mode, but I'm not aware of > anyone trying VFIO-noiommu at all. That's probably expected since it's > Christmas/New Year in a lot of places, and everyone is on a break. > > That said, I'm not sure I completely understand what is it that you're asking > about. The code you're referring to (in vfio_pci.c, line 854 as of kernel > 4.3) is checking if a PCI BAR is available for IO (hence checking if the > IORESOURCE_MEM Thanks for reply! You comment might help to move this discuss to next level. Look at kernel/resource.c, it exports two symbol ioport_resource and iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec) uses pci _io bar region for device initialization as virtio headers are locate at pci _io bar region. Since it uses pci _iobar region so likely it update pci_resource.[index].flag = IORESOURCE_IO. and vfio mmap function wont handle ioresource_io (i guess). And that is why I asked same to lkml thread. bit is set). There isn't any "ioresource_mem" region as far as VFIO is concerned, there are only BARs, ROM, VGA and PCI config regions (linux/vfio.h, line 314 as of kernel 4.3). So if you're missing some PCI regions for VFIO to map, they would first need to be added to VFIO kernel implementation before they can be used by DPDK. That is, unless I'm misunderstanding something :) > Agree. As mentioned above, I guess ioresource_io pci bar implementation missing in vfio kernel? but before adding code support in kernel I would like to hear from experts example, You, Alex! (looping alex) > Thanks, > Anatoly
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
Hi Santosh, > Look at kernel/resource.c, it exports two symbol ioport_resource and > iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and > IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. > _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec) uses pci > _io bar region for device initialization as virtio headers are locate at pci > _io bar > region. Since it uses pci _iobar region so likely it update > pci_resource.[index].flag = IORESOURCE_IO. and vfio mmap function wont > handle ioresource_io (i guess). And that is why I asked same to lkml thread. Yes, I can see that this is what I was misunderstanding (that IORESOURCE_IO isn't a BAR but rather a flag). Technically, if you also set IORESOURCE_MEM along with IORESOURCE_IO, then the BAR would be mapped by VFIO, but this sounds like a dangerous hack :) other than that, yes, I'm afraid it's up to kernel guys to add support for it. Once done, provided IO BARs are meant to be worked with the same way as MEM BARs, there's a good chance it would work out of the box with DPDK. Thanks, Anatoly
[dpdk-dev] [PATCH 0/6 for 2.3] initial virtio 1.0 enabling
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu > Sent: Thursday, December 10, 2015 11:54 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/6 for 2.3] initial virtio 1.0 enabling > > Hi, > > Here is an initial virtio 1.0 pmd driver enabling. > > Almost all difference comes from virtio 1.0 are the PCI layout change: > the major configuration structures are stored at bar space, and their > location is stored at corresponding pci cap structure. Reading/parsing > them is one of the major work of patch 6. > > To make handling virtio v1.0 and v0.95 co-exist well, this patch set > introduces a virtio_pci_ops structure, to add another layer so that > we could keep those vtpci_foo_bar "APIs". With that, we could do the > minimum change to add virtio 1.0 support. Please point out from which version, qemu starts to support virtio 1.0 net devices. Thanks, Jianfeng > > Note that the enabling is still in rough state, and it's likely I may > miss something. So, comments are huge welcome! > > --yliu > > --- > Yuanhan Liu (6): > virtio: don't set vring address again at queue startup > virtio: introduce struct virtio_pci_ops > virtio: move left pci stuff to virtio_pci.c > viritio: switch to 64 bit features > virtio: set RTE_PCI_DRV_NEED_MAPPING flag > virtio: add virtio v1.0 support > > drivers/net/virtio/virtio_ethdev.c | 297 +-- > drivers/net/virtio/virtio_ethdev.h | 3 +- > drivers/net/virtio/virtio_pci.c| 752 > +++-- > drivers/net/virtio/virtio_pci.h| 100 - > drivers/net/virtio/virtio_rxtx.c | 15 - > drivers/net/virtio/virtqueue.h | 4 +- > 6 files changed, 843 insertions(+), 328 deletions(-) > > -- > 1.9.0
[dpdk-dev] [PATCH 2/6] virtio: introduce struct virtio_pci_ops
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu
> Sent: Thursday, December 10, 2015 11:54 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/6] virtio: introduce struct virtio_pci_ops
>
> Introduce struct virtio_pci_ops, to let legacy virtio (v0.95) and
> modern virtio (1.0) have different implementation regarding to a
> specific pci action, such as read host status.
>
...
> +static void
> +legacy_reset(struct virtio_hw *hw)
> +{
> + /*
> + * Setting the status to RESET sets the host device to
> + * the original, uninitialized state.
> + */
> + legacy_set_status(hw, VIRTIO_CONFIG_STATUS_RESET);
> + legacy_get_status(hw);
May need a comment to explain why here we need to get_status().
> +}
> +
> +static uint8_t
> +legacy_get_isr(struct virtio_hw *hw)
> +{
Please delete the following blank line.
> +
> + return VIRTIO_READ_REG_1(hw, VIRTIO_PCI_ISR);
> +}
> +
> +/* Enable one vector (0) for Link State Intrerrupt */
> +static uint16_t
> +legacy_set_irq(struct virtio_hw *hw, uint16_t vec)
> +{
> + VIRTIO_WRITE_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR, vec);
> + return VIRTIO_READ_REG_2(hw, VIRTIO_MSI_CONFIG_VECTOR);
> +}
> +
...
> +
> +struct virtio_pci_ops {
> + void (*read_dev_cfg)(struct virtio_hw *hw, uint64_t offset,
> + void *dst, int len);
> + void (*write_dev_cfg)(struct virtio_hw *hw, uint64_t offset,
> + void *src, int len);
> + void (*reset)(struct virtio_hw *hw);
> +
> + uint8_t (*get_status)(struct virtio_hw *hw);
> + void(*set_status)(struct virtio_hw *hw, uint8_t status);
> +
> + uint32_t (*get_features)(struct virtio_hw *hw);
> + void (*set_features)(struct virtio_hw *hw, uint32_t features);
> +
> + uint8_t (*get_isr)(struct virtio_hw *hw);
> +
> + uint16_t (*set_irq)(struct virtio_hw *hw, uint16_t vec);
> +
> + uint16_t (*get_queue_num)(struct virtio_hw *hw, uint16_t
> queue_id);
How about changing the name into get_queue_size? From my side, queue_num is
very confusing.
Thanks,
Jianfeng
> + void (*setup_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> + void (*del_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> + void (*notify_queue)(struct virtio_hw *hw, struct virtqueue *vq);
> +};
> +
...
> #ifdef RTE_LIBRTE_VIRTIO_DEBUG_DUMP
> --
> 1.9.0
[dpdk-dev] [PATCH 6/6] virtio: add virtio v1.0 support
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yuanhan Liu
> Sent: Thursday, December 10, 2015 11:54 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 6/6] virtio: add virtio v1.0 support
>
...
> Signed-off-by: Yuanhan Liu
> ---
> drivers/net/virtio/virtio_ethdev.c | 16 +-
> drivers/net/virtio/virtio_ethdev.h | 3 +-
> drivers/net/virtio/virtio_pci.c| 313
> -
> drivers/net/virtio/virtio_pci.h| 65
> drivers/net/virtio/virtqueue.h | 2 +
> 5 files changed, 395 insertions(+), 4 deletions(-)
>
As legacy VIRTIO_WRITE_REG_XXXs are only used in virtio_pci.c, move these
definitions into virtio_pci.c?
> diff --git a/drivers/net/virtio/virtio_ethdev.c
> b/drivers/net/virtio/virtio_ethdev.c
> index 9847ed8..1f9de01 100644
> --- a/drivers/net/virtio/virtio_ethdev.c
> +++ b/drivers/net/virtio/virtio_ethdev.c
> @@ -927,7 +927,7 @@ virtio_vlan_filter_set(struct rte_eth_dev *dev,
> uint16_t vlan_id, int on)
> return virtio_send_command(hw->cvq, &ctrl, &len, 1);
> }
>
> -static void
> +static int
> virtio_negotiate_features(struct virtio_hw *hw)
> {
> uint64_t host_features;
> @@ -949,6 +949,17 @@ virtio_negotiate_features(struct virtio_hw *hw)
> hw->guest_features = vtpci_negotiate_features(hw, host_features);
> PMD_INIT_LOG(DEBUG, "features after negotiate = %"PRIx64,
> hw->guest_features);
> +
> + if (hw->modern) {
> + if (!vtpci_with_feature(hw, VIRTIO_F_VERSION_1)) {
> + PMD_INIT_LOG(ERR,
> + "VIRTIO_F_VERSION_1 features is not
> enabled");
> + return -1;
> + }
> + vtpci_set_status(hw,
> VIRTIO_CONFIG_STATUS_FEATURES_OK);
As per Linux code drivers/virtio/virtio.c:virtio_finalize_features(),
vtpci_set_status() may fail, and there's a double check.
Is it necessary here?
> + }
> +
> + return 0;
> }
>
> /*
> @@ -1032,7 +1043,8 @@ eth_virtio_dev_init(struct rte_eth_dev *eth_dev)
>
> /* Tell the host we've known how to drive the device. */
> vtpci_set_status(hw, VIRTIO_CONFIG_STATUS_DRIVER);
> - virtio_negotiate_features(hw);
> + if (virtio_negotiate_features(hw) < 0)
> + return -1;
>
> /* If host does not support status then disable LSC */
> if (!vtpci_with_feature(hw, VIRTIO_NET_F_STATUS))
> diff --git a/drivers/net/virtio/virtio_ethdev.h
> b/drivers/net/virtio/virtio_ethdev.h
> index ae2d47d..fed9571 100644
> --- a/drivers/net/virtio/virtio_ethdev.h
> +++ b/drivers/net/virtio/virtio_ethdev.h
> @@ -64,7 +64,8 @@
>1u << VIRTIO_NET_F_CTRL_VQ | \
>1u << VIRTIO_NET_F_CTRL_RX | \
>1u << VIRTIO_NET_F_CTRL_VLAN | \
> - 1u << VIRTIO_NET_F_MRG_RXBUF)
> + 1u << VIRTIO_NET_F_MRG_RXBUF | \
> + 1ULL << VIRTIO_F_VERSION_1)
>
> /*
> * CQ function prototype
> diff --git a/drivers/net/virtio/virtio_pci.c b/drivers/net/virtio/virtio_pci.c
> index 26b0a0c..7862d7f 100644
> --- a/drivers/net/virtio/virtio_pci.c
> +++ b/drivers/net/virtio/virtio_pci.c
> @@ -31,6 +31,7 @@
> * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
> DAMAGE.
> */
> #include
> +#include
Put this "include" into macro RTE_EXEC_ENV_LINUXAPP followed?
>
> #ifdef RTE_EXEC_ENV_LINUXAPP
> #include
> @@ -448,6 +449,205 @@ static const struct virtio_pci_ops legacy_ops = {
> };
>
>
...
> +
> +static uint16_t
> +modern_set_irq(struct virtio_hw *hw __rte_unused, uint16_t vec
> __rte_unused)
> +{
> + /* FIXME: xxx */
> + return 0;
> +}
If not going to support LSC, please give clear indication at related doc. My
concern is: this will affect
some users, who are using LSC in legacy virtio. (If LSC works well on legacy
virtio?).
> +
> +static uint16_t
> +modern_get_queue_num(struct virtio_hw *hw, uint16_t queue_id)
> +{
> + modern_write16(queue_id, &hw->common_cfg->queue_select);
> + return modern_read16(&hw->common_cfg->queue_size);
> +}
> +
...
>
> +static inline void *
> +get_cfg_addr(struct rte_pci_device *dev, struct virtio_pci_cap *cap)
> +{
> + uint8_t bar= cap->bar;
> + uint32_t length = cap->length;
> + uint32_t offset = cap->offset;
> + uint8_t *base;
> +
Use a macro to substitute hardcoded "5"?
> + if (unlikely(bar > 5)) {
> + PMD_INIT_LOG(ERR, "invalid bar: %u", bar);
> + return NULL;
> + }
> +
...
> int
> vtpci_init(struct rte_pci_device *dev, struct virtio_hw *hw)
> {
> - hw->vtpci_ops = &legacy_ops;
> + hw->dev = dev;
>
> + /*
> + * Try if we can succeed reading virtio pci caps, which exists
> + * only on modern pci device. If failed, we fallback to legacy
> + * virtio hanlding.
hanlding -> handling
Thanks,
Jianfeng
> + */
...
> +
> struct vq_desc_extra {
> void *cookie;
> uint16
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
On Tue, Dec 29, 2015 at 4:36 PM, Burakov, Anatoly wrote: > Hi Santosh, > >> Look at kernel/resource.c, it exports two symbol ioport_resource and >> iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and >> IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. >> _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec) uses pci >> _io bar region for device initialization as virtio headers are locate at pci >> _io bar >> region. Since it uses pci _iobar region so likely it update >> pci_resource.[index].flag = IORESOURCE_IO. and vfio mmap function wont >> handle ioresource_io (i guess). And that is why I asked same to lkml thread. > > Yes, I can see that this is what I was misunderstanding (that IORESOURCE_IO > isn't a BAR but rather a flag). Technically, if you also set IORESOURCE_MEM > along with IORESOURCE_IO, then the BAR would be mapped by VFIO, but this > sounds like a dangerous hack :) other than that, yes, I'm afraid it's up to > kernel guys to add support for it. Once done, provided IO BARs are meant to > be worked with the same way as MEM BARs, there's a good chance it would work > out of the box with DPDK. > I guess so, I'll give it a try; although before that I need to port / use your vfio/noiommu patch for virtio pmd driver and perhaps do dependant changes, I will post my test feedback. Thanks > Thanks, > Anatoly
[dpdk-dev] [PATCH v3 3/3] examples/l3fwd: Handle SIGINT and SIGTERM in l3fwd
> -Original Message-
> From: Wang, Zhihong
> Sent: Tuesday, December 29, 2015 1:21 AM
> To: dev at dpdk.org
> Cc: Ananyev, Konstantin; stephen at networkplumber.org; Qiu, Michael; Wang,
> Zhihong
> Subject: [PATCH v3 3/3] examples/l3fwd: Handle SIGINT and SIGTERM in l3fwd
>
> Handle SIGINT and SIGTERM in l3fwd.
>
> Signed-off-by: Zhihong Wang
> Acked-by: Michael Qiu
> ---
> examples/l3fwd/main.c | 129
> +-
> 1 file changed, 107 insertions(+), 22 deletions(-)
>
> diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
> index 5b0c2dd..c766cf5 100644
> --- a/examples/l3fwd/main.c
> +++ b/examples/l3fwd/main.c
> @@ -41,6 +41,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
> #include
> @@ -75,6 +78,10 @@
> #include
> #include
>
> +static volatile bool port_started;
> +static volatile bool force_quit;
> +static volatile int signo_quit;
> +
> #define APP_LOOKUP_EXACT_MATCH 0
> #define APP_LOOKUP_LPM 1
> #define DO_RFC_1812_CHECKS
> @@ -1553,8 +1560,7 @@ main_loop(__attribute__((unused)) void *dummy)
> portid, queueid);
> }
>
> - while (1) {
> -
> + while (!force_quit) {
> cur_tsc = rte_rdtsc();
>
> /*
> @@ -2516,8 +2522,12 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
> port_mask)
> printf("\nChecking link status");
> fflush(stdout);
> for (count = 0; count <= MAX_CHECK_TIME; count++) {
> + if (force_quit)
> + return;
> all_ports_up = 1;
> for (portid = 0; portid < port_num; portid++) {
> + if (force_quit)
> + return;
> if ((port_mask & (1 << portid)) == 0)
> continue;
> memset(&link, 0, sizeof(link));
> @@ -2559,6 +2569,76 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
> port_mask)
> }
> }
>
> +static uint8_t
> +start_ports(void)
> +{
> + unsigned portid, nb_ports, avail_ports;
> + int ret;
> +
> + nb_ports = rte_eth_dev_count();
> + avail_ports = 0;
> + for (portid = 0; portid < nb_ports; portid++) {
> + if ((enabled_port_mask & (1 << portid)) == 0)
> + continue;
> + avail_ports++;
> + port_started = true;
Why do you need it at each iteration?
> + printf("Starting port %d...", portid);
> + ret = rte_eth_dev_start(portid);
> + if (ret < 0)
> + rte_exit(EXIT_FAILURE,
> + "rte_eth_dev_start: err=%d, port=%d\n",
> + ret, portid);
> + /*
> + * If enabled, put device in promiscuous mode.
> + * This allows IO forwarding mode to forward packets
> + * to itself through 2 cross-connected ports of the
> + * target machine.
> + */
> + if (promiscuous_on)
> + rte_eth_promiscuous_enable(portid);
> + printf(" Done\n");
> + }
> +
> + return avail_ports;
> +}
> +
> +static void
> +stop_ports(void)
> +{
> + unsigned portid, nb_ports;
> +
> + nb_ports = rte_eth_dev_count();
> + for (portid = 0; portid < nb_ports; portid++) {
> + if ((enabled_port_mask & (1 << portid)) == 0)
> + continue;
> + printf("Stopping port %d...", portid);
> + rte_eth_dev_stop(portid);
> + rte_eth_dev_close(portid);
> + printf(" Done\n");
> + }
> + port_started = false;
> +}
> +
> +static void
> +signal_handler(int signum)
> +{
> + if (signum == SIGINT || signum == SIGTERM) {
> + printf("\nSignal %d received, preparing to exit...\n",
> + signum);
> + if (port_started) {
> + printf("Ports started already...\n");
> + signo_quit = signum;
> + force_quit = true;
> + } else {
Hmm, and what if signal_handler() would be executed not in the context of
master lcore?
Then there could be a raise condition, and you could end up here, while master
lcore
would be in the middle of start_ports()->rte_eth_dev_start().
Probably not a big deal, but why do you need this if (port_started) {...} else
{...} at all?
Why not just:
signal_handler(int signum)
{
signo_quit = signum;
force_quit = true;
}
?
Konstantin
> + printf("Ports not started yet...\n");
> + printf("Bye...\n");
> + /* exit with the expected status */
> + signal(signum, SIG_DFL);
> + kill(getpid(), signum);
> + }
> + }
> +}
> +
> int
> main(int argc, char **argv)
> {
> @@
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
On Tue, 2015-12-29 at 16:17 +0530, Santosh Shukla wrote: > On Tue, Dec 29, 2015 at 3:26 PM, Burakov, Anatoly > wrote: > > Hi Santosh, > > > > > On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla > > om> > > > wrote: > > > > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu > > > > wrote: > > > > > On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla > > > > > wrote: > > > > > > > > I guess we have done enough evaluation / investigation > > > > > > > > that > > > > > > > > suggest - so to map iopci region to userspace in arch > > > > > > > > agnostic-way - > > > > > > > > > > > > > > > > # either we need to modify kernel > > > > > > > > ???- Make sure all the non-x86 arch to > > > > > > > > support > > > > > > > > mapping for iopci region (i.e. pci_mmap_page_range). I > > > > > > > > don;t > > > > > > > > think its a correct approach though. > > > > > > > > or > > > > > > > > ???- include /dev/ioport char-mem device > > > > > > > > file who > > > > > > > > could do more than byte operation, Note that this > > > > > > > > implementation > > > > > > > > does not exist in kernel.??I could send an RFC to lkml. > > > > > > > > > > > > > > Maybe you could propose the two to lkml, to get some > > > > > > > feedbacks > > > > > > > from those kernel/ARM gurus? Please cc me if you do so. > > > > > > > > > > > > > > > > > > > The latter one I already shared old lkml thread, Pl. > > > > > > revisit my v1 > > > > > > 0/6 patch [1] and in that refer [2]. > > > > > > > > > > Oops, sorry, a bit busy, that I didn't look at it carefully. > > > > > My bad, > > > > > anyway. > > > > > > > > > > > Josh has already proposed to lkml but for some reason > > > > > > thread didn't > > > > > > went far. I can restart that discussion giving dpdk use- > > > > > > case as an > > > > > > example/ requirement. > > > > > > > > > > I had a quick go through of the discussion. Both hpa and Arnd > > > > > seem to > > > > > be fine with the ioctl interface on /dev/port. Have you tried > > > > > that? > > > > > And if you want to restart it, ioctl might be a better option > > > > > than > > > > > /dev/ioport, judging from the discussion. > > > > > > > > > > > > > I tried legacy patch and re-writing with ioctl-way; doing > > > > changes in > > > > dpdk port as well in kernel, had to test on quite other hw not > > > > only > > > > arm64 though! so it will take time for me, I am travelling > > > > tomorrow so > > > > bit delayed, We'll post patch to lkml and share dpdk-virtio > > > > feedback > > > > perhaps by Monday. > > > > > > > > > > I posted a query about /dev/ioports approach in lkml thread [1], > > > and Arnd > > > suggested to use vfio framework but it looks like vfio too does > > > not map > > > ioresource_io region. Same communicated to Arnd and waiting for > > > his reply. > > > > > > In mean time I like to ask general question; > > > - Has anyone tried vfio/non-iommu approach for virtio pmd driver? > > > If not > > > then Is there any plan? Someone planning to take up. > > > [1] https://lkml.org/lkml/2015/12/23/145 > > > > I have submitted a patch to support no-iommu mode, but I'm not > > aware of anyone trying VFIO-noiommu at all. That's probably > > expected since it's Christmas/New Year in a lot of places, and > > everyone is on a break. > > > > That said, I'm not sure I completely understand what is it that > > you're asking about. The code you're referring to (in vfio_pci.c, > > line 854 as of kernel 4.3) is checking if a PCI BAR is available > > for IO (hence checking if the IORESOURCE_MEM > > > Thanks for reply! You comment might help to move this discuss to next > level. > > Look at kernel/resource.c, it exports two symbol ioport_resource and > iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and > IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. > _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec) > uses pci _io bar region for device initialization as virtio headers > are locate at pci _io bar region. Since it uses pci _iobar region so > likely it update pci_resource.[index].flag = IORESOURCE_IO.??and vfio > mmap function wont handle ioresource_io (i guess). And that is why I > asked same to lkml thread. > > > bit is set). There isn't any "ioresource_mem" region as far as VFIO > is > concerned, there are only BARs, ROM, VGA and PCI > config regions (linux/vfio.h, line 314 as of kernel 4.3). So if > you're > missing some PCI regions for VFIO to map, they would first need to be > added to VFIO kernel implementation before they can be used by DPDK. > That is, unless I'm misunderstanding something :) > > > > Agree. As mentioned above, I guess ioresource_io pci bar > implementation missing in vfio kernel? but before adding code support > in kernel I would like to hear from experts example, You, Alex! > (looping alex) MMIO and I/O port space are simply regions as far as VFIO is concerned. ?The userspace API supports the con
[dpdk-dev] [PATCH] eal: map io resources for non x86 architectures
On Tue, Dec 29, 2015 at 7:34 PM, Alex Williamson wrote: > On Tue, 2015-12-29 at 16:17 +0530, Santosh Shukla wrote: >> On Tue, Dec 29, 2015 at 3:26 PM, Burakov, Anatoly >> wrote: >> > Hi Santosh, >> > >> > > On Fri, Dec 18, 2015 at 6:25 PM, Santosh Shukla > > > om> >> > > wrote: >> > > > On Fri, Dec 18, 2015 at 1:51 PM, Yuanhan Liu >> > > > wrote: >> > > > > On Fri, Dec 18, 2015 at 01:24:41PM +0530, Santosh Shukla >> > > > > wrote: >> > > > > > > > I guess we have done enough evaluation / investigation >> > > > > > > > that >> > > > > > > > suggest - so to map iopci region to userspace in arch >> > > > > > > > agnostic-way - >> > > > > > > > >> > > > > > > > # either we need to modify kernel >> > > > > > > >- Make sure all the non-x86 arch to >> > > > > > > > support >> > > > > > > > mapping for iopci region (i.e. pci_mmap_page_range). I >> > > > > > > > don;t >> > > > > > > > think its a correct approach though. >> > > > > > > > or >> > > > > > > >- include /dev/ioport char-mem device >> > > > > > > > file who >> > > > > > > > could do more than byte operation, Note that this >> > > > > > > > implementation >> > > > > > > > does not exist in kernel. I could send an RFC to lkml. >> > > > > > > >> > > > > > > Maybe you could propose the two to lkml, to get some >> > > > > > > feedbacks >> > > > > > > from those kernel/ARM gurus? Please cc me if you do so. >> > > > > > > >> > > > > > >> > > > > > The latter one I already shared old lkml thread, Pl. >> > > > > > revisit my v1 >> > > > > > 0/6 patch [1] and in that refer [2]. >> > > > > >> > > > > Oops, sorry, a bit busy, that I didn't look at it carefully. >> > > > > My bad, >> > > > > anyway. >> > > > > >> > > > > > Josh has already proposed to lkml but for some reason >> > > > > > thread didn't >> > > > > > went far. I can restart that discussion giving dpdk use- >> > > > > > case as an >> > > > > > example/ requirement. >> > > > > >> > > > > I had a quick go through of the discussion. Both hpa and Arnd >> > > > > seem to >> > > > > be fine with the ioctl interface on /dev/port. Have you tried >> > > > > that? >> > > > > And if you want to restart it, ioctl might be a better option >> > > > > than >> > > > > /dev/ioport, judging from the discussion. >> > > > > >> > > > >> > > > I tried legacy patch and re-writing with ioctl-way; doing >> > > > changes in >> > > > dpdk port as well in kernel, had to test on quite other hw not >> > > > only >> > > > arm64 though! so it will take time for me, I am travelling >> > > > tomorrow so >> > > > bit delayed, We'll post patch to lkml and share dpdk-virtio >> > > > feedback >> > > > perhaps by Monday. >> > > > >> > > >> > > I posted a query about /dev/ioports approach in lkml thread [1], >> > > and Arnd >> > > suggested to use vfio framework but it looks like vfio too does >> > > not map >> > > ioresource_io region. Same communicated to Arnd and waiting for >> > > his reply. >> > > >> > > In mean time I like to ask general question; >> > > - Has anyone tried vfio/non-iommu approach for virtio pmd driver? >> > > If not >> > > then Is there any plan? Someone planning to take up. >> > > [1] https://lkml.org/lkml/2015/12/23/145 >> > >> > I have submitted a patch to support no-iommu mode, but I'm not >> > aware of anyone trying VFIO-noiommu at all. That's probably >> > expected since it's Christmas/New Year in a lot of places, and >> > everyone is on a break. >> > >> > That said, I'm not sure I completely understand what is it that >> > you're asking about. The code you're referring to (in vfio_pci.c, >> > line 854 as of kernel 4.3) is checking if a PCI BAR is available >> > for IO (hence checking if the IORESOURCE_MEM >> >> >> Thanks for reply! You comment might help to move this discuss to next >> level. >> >> Look at kernel/resource.c, it exports two symbol ioport_resource and >> iomem_resource and sets appropriate flag type i.e.. IORESOURCE_IO and >> IORESOURCE_MEM. In virtio-net case; it creates both pci region i.e.. >> _io bar and _mem bar. dpdk virtio pmd driver (<= 0.95 virtio spec) >> uses pci _io bar region for device initialization as virtio headers >> are locate at pci _io bar region. Since it uses pci _iobar region so >> likely it update pci_resource.[index].flag = IORESOURCE_IO. and vfio >> mmap function wont handle ioresource_io (i guess). And that is why I >> asked same to lkml thread. >> >> >> bit is set). There isn't any "ioresource_mem" region as far as VFIO >> is >> concerned, there are only BARs, ROM, VGA and PCI >> config regions (linux/vfio.h, line 314 as of kernel 4.3). So if >> you're >> missing some PCI regions for VFIO to map, they would first need to be >> added to VFIO kernel implementation before they can be used by DPDK. >> That is, unless I'm misunderstanding something :) >> > >> >> Agree. As mentioned above, I guess ioresource_io pci bar >> implementation missing in vfio kernel? but before adding code support >> in kernel I would like to hear fr
[dpdk-dev] Packet Classification Library
Hi, I was wondering if there is any info regarding the optimization strategy for the Packet Classification Library. Any info would be appreciated. I'm curious to know if there are rules of thumb to optimize the configuration. Regards, Jason
[dpdk-dev] bnx2x pmd performance expectations
> >Thank you for pointing this out. While it seems to me problem here is RX, >I >will also look into TX burst limitations. > >-a > >On 28 December 2015 at 00:17, Chas Williams <3chas3 at gmail.com> wrote: > >> I wouldn't consider myself an expert on this driver but while looking >> at some other things, I have noted that RTE_PMD_BNX2X_TX_MAX_BURST is >> defined to be 1. This bursts single packets to bnx2x_tx_encap() but it >> looks like bnx2x_tx_encap() is far more capable than that. >> >> On Tue, 2015-12-22 at 14:52 +0300, Alexander Belyakov wrote: >> > Hi, >> > >> > just tried to forward a lot of tiny packets with testpmd (dpdk-2.2.0) >> > running on Broadcom Corporation NetXtreme II BCM57810S 10 Gigabit >> > Ethernet >> > (rev 10) adapter. I see forwarding performance of 2.6Mpps instead of >> > expected 14.8Mpps. What should be done to achieve better results? >> > >> > Thank you, >> > Alexander Belyakov >> > Alex/Chas, We have HW/FW limitation for PPS. The adapter can only do ~3 MPPS. However, yes we can revamp the Tx routines a bit to transmit multiple packets in a single burst at a time using single doorbelling mechanism. Thanks Harish This message and any attached documents contain information from the sending company or its parent company(s), subsidiaries, divisions or branch offices that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
[dpdk-dev] [PATCH 4/4] vmxnet3: announce device offload capability
Signed-off-by: Yong Wang
---
drivers/net/vmxnet3/vmxnet3_ethdev.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_ethdev.c
b/drivers/net/vmxnet3/vmxnet3_ethdev.c
index c363bf6..8a40127 100644
--- a/drivers/net/vmxnet3/vmxnet3_ethdev.c
+++ b/drivers/net/vmxnet3/vmxnet3_ethdev.c
@@ -693,7 +693,8 @@ vmxnet3_dev_stats_get(struct rte_eth_dev *dev, struct
rte_eth_stats *stats)
}
static void
-vmxnet3_dev_info_get(__attribute__((unused))struct rte_eth_dev *dev, struct
rte_eth_dev_info *dev_info)
+vmxnet3_dev_info_get(__attribute__((unused))struct rte_eth_dev *dev,
+struct rte_eth_dev_info *dev_info)
{
dev_info->max_rx_queues = VMXNET3_MAX_RX_QUEUES;
dev_info->max_tx_queues = VMXNET3_MAX_TX_QUEUES;
@@ -716,6 +717,17 @@ vmxnet3_dev_info_get(__attribute__((unused))struct
rte_eth_dev *dev, struct rte_
.nb_min = VMXNET3_DEF_TX_RING_SIZE,
.nb_align = 1,
};
+
+ dev_info->rx_offload_capa =
+ DEV_RX_OFFLOAD_VLAN_STRIP |
+ DEV_RX_OFFLOAD_UDP_CKSUM |
+ DEV_RX_OFFLOAD_TCP_CKSUM;
+
+ dev_info->tx_offload_capa =
+ DEV_TX_OFFLOAD_VLAN_INSERT |
+ DEV_TX_OFFLOAD_TCP_CKSUM |
+ DEV_TX_OFFLOAD_UDP_CKSUM |
+ DEV_TX_OFFLOAD_TCP_TSO;
}
/* return 0 means link status changed, -1 means not changed */
@@ -819,7 +831,7 @@ vmxnet3_dev_vlan_filter_set(struct rte_eth_dev *dev,
uint16_t vid, int on)
else
VMXNET3_CLEAR_VFTABLE_ENTRY(hw->shadow_vfta, vid);
- /* don't change active filter if in promiscious mode */
+ /* don't change active filter if in promiscuous mode */
if (rxConf->rxMode & VMXNET3_RXM_PROMISC)
return 0;
--
1.9.1
[dpdk-dev] [PATCH 0/4] vmxnet3 TSO and tx cksum offload
This patchset adds TCP/UDP checksum offload and TSO to vmxnet3 PMD. It also restores the tx data ring feature that was removed from a previous patch and fixes offload capability announcement. Yong Wang (4): vmxnet3: restore tx data ring support vmxnet3: add tx l4 cksum offload vmxnet3: add TSO support vmxnet3: announce device offload capability doc/guides/rel_notes/release_2_3.rst | 11 +++ drivers/net/vmxnet3/vmxnet3_ethdev.c | 16 +++- drivers/net/vmxnet3/vmxnet3_ring.h | 13 --- drivers/net/vmxnet3/vmxnet3_rxtx.c | 165 +++ 4 files changed, 156 insertions(+), 49 deletions(-) -- 1.9.1
[dpdk-dev] [PATCH 1/4] vmxnet3: restore tx data ring support
Tx data ring support was removed in a previous change
to add multi-seg transmit. This change adds it back.
Fixes: 7ba5de417e3c ("vmxnet3: support multi-segment transmit")
Signed-off-by: Yong Wang
---
doc/guides/rel_notes/release_2_3.rst | 5 +
drivers/net/vmxnet3/vmxnet3_rxtx.c | 17 -
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index 99de186..a23c8ac 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -15,6 +15,11 @@ EAL
Drivers
~~~
+* **vmxnet3: restore tx data ring.**
+
+ Tx data ring has been shown to improve small pkt forwarding performance
+ on vSphere environment.
+
Libraries
~
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 4de5d89..2202d31 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -348,6 +348,7 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint32_t first2fill, avail, dw2;
struct rte_mbuf *txm = tx_pkts[nb_tx];
struct rte_mbuf *m_seg = txm;
+ int copy_size = 0;
/* Is this packet execessively fragmented, then drop */
if (unlikely(txm->nb_segs > VMXNET3_MAX_TXD_PER_PKT)) {
@@ -365,6 +366,14 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
break;
}
+ if (rte_pktmbuf_pkt_len(txm) <= VMXNET3_HDR_COPY_SIZE) {
+ struct Vmxnet3_TxDataDesc *tdd;
+
+ tdd = txq->data_ring.base + txq->cmd_ring.next2fill;
+ copy_size = rte_pktmbuf_pkt_len(txm);
+ rte_memcpy(tdd->data, rte_pktmbuf_mtod(txm, char *),
copy_size);
+ }
+
/* use the previous gen bit for the SOP desc */
dw2 = (txq->cmd_ring.gen ^ 0x1) << VMXNET3_TXD_GEN_SHIFT;
first2fill = txq->cmd_ring.next2fill;
@@ -377,7 +386,13 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
transmit buffer size (16K) is greater than
maximum sizeof mbuf segment size. */
gdesc = txq->cmd_ring.base + txq->cmd_ring.next2fill;
- gdesc->txd.addr = RTE_MBUF_DATA_DMA_ADDR(m_seg);
+ if (copy_size)
+ gdesc->txd.addr =
rte_cpu_to_le_64(txq->data_ring.basePA +
+
txq->cmd_ring.next2fill *
+ sizeof(struct
Vmxnet3_TxDataDesc));
+ else
+ gdesc->txd.addr = RTE_MBUF_DATA_DMA_ADDR(m_seg);
+
gdesc->dword[2] = dw2 | m_seg->data_len;
gdesc->dword[3] = 0;
--
1.9.1
[dpdk-dev] [PATCH 2/4] vmxnet3: add tx l4 cksum offload
Support TCP/UDP checksum offload.
Signed-off-by: Yong Wang
---
doc/guides/rel_notes/release_2_3.rst | 3 +++
drivers/net/vmxnet3/vmxnet3_rxtx.c | 35 ---
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index a23c8ac..58205fe 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -20,6 +20,9 @@ Drivers
Tx data ring has been shown to improve small pkt forwarding performance
on vSphere environment.
+* **vmxnet3: add tx l4 cksum offload.**
+
+ Support TCP/UDP checksum offload.
Libraries
~
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 2202d31..550a13f 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -332,6 +332,8 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_tx;
vmxnet3_tx_queue_t *txq = tx_queue;
struct vmxnet3_hw *hw = txq->hw;
+ Vmxnet3_TxQueueCtrl *txq_ctrl = &txq->shared->ctrl;
+ uint32_t deferred = rte_le_to_cpu_32(txq_ctrl->txNumDeferred);
if (unlikely(txq->stopped)) {
PMD_TX_LOG(DEBUG, "Tx queue is stopped.");
@@ -413,21 +415,40 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
gdesc->txd.tci = txm->vlan_tci;
}
- /* TODO: Add transmit checksum offload here */
+ if (txm->ol_flags & PKT_TX_L4_MASK) {
+ gdesc->txd.om = VMXNET3_OM_CSUM;
+ gdesc->txd.hlen = txm->l2_len + txm->l3_len;
+
+ switch (txm->ol_flags & PKT_TX_L4_MASK) {
+ case PKT_TX_TCP_CKSUM:
+ gdesc->txd.msscof = gdesc->txd.hlen +
offsetof(struct tcp_hdr, cksum);
+ break;
+ case PKT_TX_UDP_CKSUM:
+ gdesc->txd.msscof = gdesc->txd.hlen +
offsetof(struct udp_hdr, dgram_cksum);
+ break;
+ default:
+ PMD_TX_LOG(WARNING, "requested cksum offload
not supported %#x",
+ txm->ol_flags & PKT_TX_L4_MASK);
+ abort();
+ }
+ } else {
+ gdesc->txd.hlen = 0;
+ gdesc->txd.om = VMXNET3_OM_NONE;
+ gdesc->txd.msscof = 0;
+ }
+
+ txq_ctrl->txNumDeferred = rte_cpu_to_le_32(++deferred);
/* flip the GEN bit on the SOP */
rte_compiler_barrier();
gdesc->dword[2] ^= VMXNET3_TXD_GEN;
-
- txq->shared->ctrl.txNumDeferred++;
nb_tx++;
}
- PMD_TX_LOG(DEBUG, "vmxnet3 txThreshold: %u",
txq->shared->ctrl.txThreshold);
-
- if (txq->shared->ctrl.txNumDeferred >= txq->shared->ctrl.txThreshold) {
+ PMD_TX_LOG(DEBUG, "vmxnet3 txThreshold: %u",
rte_le_to_cpu_32(txq_ctrl.txThreshold));
- txq->shared->ctrl.txNumDeferred = 0;
+ if (deferred >= rte_le_to_cpu_32(txq_ctrl->txThreshold)) {
+ txq_ctrl->txNumDeferred = 0;
/* Notify vSwitch that packets are available. */
VMXNET3_WRITE_BAR0_REG(hw, (VMXNET3_REG_TXPROD + txq->queue_id
* VMXNET3_REG_ALIGN),
txq->cmd_ring.next2fill);
--
1.9.1
[dpdk-dev] [PATCH 3/4] vmxnet3: add TSO support
This commit adds vmxnet3 TSO support.
Verified with test-pmd (set fwd csum) that both tso and non-tso
pkts can be successfully transmitted and all segmentes for a tso
pkt are correct on the receiver side.
Signed-off-by: Yong Wang
---
doc/guides/rel_notes/release_2_3.rst | 3 +
drivers/net/vmxnet3/vmxnet3_ring.h | 13
drivers/net/vmxnet3/vmxnet3_rxtx.c | 117 ++-
3 files changed, 92 insertions(+), 41 deletions(-)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes/release_2_3.rst
index 58205fe..ae487bb 100644
--- a/doc/guides/rel_notes/release_2_3.rst
+++ b/doc/guides/rel_notes/release_2_3.rst
@@ -24,6 +24,9 @@ Drivers
Support TCP/UDP checksum offload.
+* **vmxnet3: add TSO support.**
+
+
Libraries
~
diff --git a/drivers/net/vmxnet3/vmxnet3_ring.h
b/drivers/net/vmxnet3/vmxnet3_ring.h
index 612487e..15b19e1 100644
--- a/drivers/net/vmxnet3/vmxnet3_ring.h
+++ b/drivers/net/vmxnet3/vmxnet3_ring.h
@@ -130,18 +130,6 @@ struct vmxnet3_txq_stats {
uint64_ttx_ring_full;
};
-typedef struct vmxnet3_tx_ctx {
- int ip_type;
- bool is_vlan;
- bool is_cso;
-
- uint16_t evl_tag; /* only valid when is_vlan == TRUE */
- uint32_t eth_hdr_size; /* only valid for pkts requesting tso or csum
-* offloading */
- uint32_t ip_hdr_size;
- uint32_t l4_hdr_size;
-} vmxnet3_tx_ctx_t;
-
typedef struct vmxnet3_tx_queue {
struct vmxnet3_hw*hw;
struct vmxnet3_cmd_ring cmd_ring;
@@ -155,7 +143,6 @@ typedef struct vmxnet3_tx_queue {
uint8_t port_id; /**< Device port
identifier. */
} vmxnet3_tx_queue_t;
-
struct vmxnet3_rxq_stats {
uint64_t drop_total;
uint64_t drop_err;
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c
b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index 550a13f..4fa18fd 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -295,27 +295,46 @@ vmxnet3_dev_clear_queues(struct rte_eth_dev *dev)
}
}
+static int
+vmxnet3_unmap_pkt(uint16_t eop_idx, vmxnet3_tx_queue_t *txq)
+{
+ int completed = 0;
+ struct rte_mbuf *mbuf;
+
+ /* Release cmd_ring descriptor and free mbuf */
+ VMXNET3_ASSERT(txq->cmd_ring.base[eop_idx].txd.eop == 1);
+
+ mbuf = txq->cmd_ring.buf_info[eop_idx].m;
+ if (unlikely(mbuf == NULL))
+ rte_panic("EOP desc does not point to a valid mbuf");
+ else
+ rte_pktmbuf_free(mbuf);
+
+ txq->cmd_ring.buf_info[eop_idx].m = NULL;
+
+ while (txq->cmd_ring.next2comp != eop_idx) {
+ /* no out-of-order completion */
+
VMXNET3_ASSERT(txq->cmd_ring.base[txq->cmd_ring.next2comp].txd.cq == 0);
+ vmxnet3_cmd_ring_adv_next2comp(&txq->cmd_ring);
+ completed++;
+ }
+
+ /* Mark the txd for which tcd was generated as completed */
+ vmxnet3_cmd_ring_adv_next2comp(&txq->cmd_ring);
+
+ return completed + 1;
+}
+
static void
vmxnet3_tq_tx_complete(vmxnet3_tx_queue_t *txq)
{
int completed = 0;
- struct rte_mbuf *mbuf;
vmxnet3_comp_ring_t *comp_ring = &txq->comp_ring;
struct Vmxnet3_TxCompDesc *tcd = (struct Vmxnet3_TxCompDesc *)
(comp_ring->base + comp_ring->next2proc);
while (tcd->gen == comp_ring->gen) {
- /* Release cmd_ring descriptor and free mbuf */
- VMXNET3_ASSERT(txq->cmd_ring.base[tcd->txdIdx].txd.eop == 1);
- while (txq->cmd_ring.next2comp != tcd->txdIdx) {
- mbuf =
txq->cmd_ring.buf_info[txq->cmd_ring.next2comp].m;
- txq->cmd_ring.buf_info[txq->cmd_ring.next2comp].m =
NULL;
- rte_pktmbuf_free_seg(mbuf);
-
- /* Mark the txd for which tcd was generated as
completed */
- vmxnet3_cmd_ring_adv_next2comp(&txq->cmd_ring);
- completed++;
- }
+ completed += vmxnet3_unmap_pkt(tcd->txdIdx, txq);
vmxnet3_comp_ring_adv_next2proc(comp_ring);
tcd = (struct Vmxnet3_TxCompDesc *)(comp_ring->base +
@@ -325,6 +344,13 @@ vmxnet3_tq_tx_complete(vmxnet3_tx_queue_t *txq)
PMD_TX_LOG(DEBUG, "Processed %d tx comps & command descs.", completed);
}
+/* The number of descriptors that are needed for a packet. */
+static unsigned
+txd_estimate(const struct rte_mbuf *m)
+{
+ return m->nb_segs;
+}
+
uint16_t
vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
@@ -351,21 +377,42 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf
**tx_pkts,
struct rte_mbuf *txm = tx_pkts[nb_tx];
struct rte_mbuf *m_seg = txm;
in
[dpdk-dev] [PATCH v4 0/3] Handle SIGINT and SIGTERM in DPDK examples
This patch handles SIGINT and SIGTERM in testpmd, l2fwd, and l3fwd, make sure all ports are properly stopped and closed. For virtual ports, the stop and close function may deal with resource cleanup, such as socket files unlinking. -- Changes in v4: 1. Add port status control in l2fwd and l3fwd -- Changes in v3: 1. Make sure correct port operations regarding status 2. Small fixes to make the code clearer -- Changes in v2: 1. Make sure graceful exit for all running phases 2. Make sure program exits with the right status Zhihong Wang (3): app/test-pmd: Handle SIGINT and SIGTERM in testpmd examples/l2fwd: Handle SIGINT and SIGTERM in l2fwd examples/l3fwd: Handle SIGINT and SIGTERM in l3fwd app/test-pmd/cmdline.c | 20 +++--- app/test-pmd/testpmd.c | 39 ++-- app/test-pmd/testpmd.h | 1 + examples/l2fwd/main.c | 161 --- examples/l3fwd/main.c | 167 ++--- 5 files changed, 331 insertions(+), 57 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH v4 1/3] app/test-pmd: Handle SIGINT and SIGTERM in testpmd
Handle SIGINT and SIGTERM in testpmd.
Signed-off-by: Zhihong Wang
Acked-by: Michael Qiu
---
app/test-pmd/cmdline.c | 20 +---
app/test-pmd/testpmd.c | 39 +--
app/test-pmd/testpmd.h | 1 +
3 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 73298c9..6d28c1b 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -90,6 +90,8 @@
#include "testpmd.h"
+static struct cmdline *testpmd_cl;
+
static void cmd_reconfig_device_queue(portid_t id, uint8_t dev, uint8_t queue);
#ifdef RTE_NIC_BYPASS
@@ -9778,17 +9780,21 @@ cmdline_parse_ctx_t main_ctx[] = {
void
prompt(void)
{
- struct cmdline *cl;
-
/* initialize non-constant commands */
cmd_set_fwd_mode_init();
- cl = cmdline_stdin_new(main_ctx, "testpmd> ");
- if (cl == NULL) {
+ testpmd_cl = cmdline_stdin_new(main_ctx, "testpmd> ");
+ if (testpmd_cl == NULL)
return;
- }
- cmdline_interact(cl);
- cmdline_stdin_exit(cl);
+ cmdline_interact(testpmd_cl);
+ cmdline_stdin_exit(testpmd_cl);
+}
+
+void
+prompt_exit(void)
+{
+ if (testpmd_cl != NULL)
+ cmdline_quit(testpmd_cl);
}
static void
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 98ae46d..1319917 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1570,13 +1570,16 @@ pmd_test_exit(void)
if (test_done == 0)
stop_packet_forwarding();
- FOREACH_PORT(pt_id, ports) {
- printf("Stopping port %d...", pt_id);
- fflush(stdout);
- rte_eth_dev_close(pt_id);
- printf("done\n");
+ if (ports != NULL) {
+ no_link_check = 1;
+ FOREACH_PORT(pt_id, ports) {
+ printf("\nShutting down port %d...\n", pt_id);
+ fflush(stdout);
+ stop_port(pt_id);
+ close_port(pt_id);
+ }
}
- printf("bye...\n");
+ printf("\nBye...\n");
}
typedef void (*cmd_func_t)(void);
@@ -1984,12 +1987,35 @@ init_port(void)
ports[pid].enabled = 1;
}
+static void
+force_quit(void)
+{
+ pmd_test_exit();
+ prompt_exit();
+}
+
+static void
+signal_handler(int signum)
+{
+ if (signum == SIGINT || signum == SIGTERM) {
+ printf("\nSignal %d received, preparing to exit...\n",
+ signum);
+ force_quit();
+ /* exit with the expected status */
+ signal(signum, SIG_DFL);
+ kill(getpid(), signum);
+ }
+}
+
int
main(int argc, char** argv)
{
int diag;
uint8_t port_id;
+ signal(SIGINT, signal_handler);
+ signal(SIGTERM, signal_handler);
+
diag = rte_eal_init(argc, argv);
if (diag < 0)
rte_panic("Cannot init EAL\n");
@@ -2041,6 +2067,7 @@ main(int argc, char** argv)
start_packet_forwarding(0);
printf("Press enter to exit\n");
rc = read(0, &c, 1);
+ pmd_test_exit();
if (rc < 0)
return 1;
}
diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h
index ee7de98..7ffc17b 100644
--- a/app/test-pmd/testpmd.h
+++ b/app/test-pmd/testpmd.h
@@ -462,6 +462,7 @@ unsigned int parse_item_list(char* str, const char*
item_name,
unsigned int *parsed_items, int check_unique_values);
void launch_args_parse(int argc, char** argv);
void prompt(void);
+void prompt_exit(void);
void nic_stats_display(portid_t port_id);
void nic_stats_clear(portid_t port_id);
void nic_xstats_display(portid_t port_id);
--
2.5.0
[dpdk-dev] [PATCH v4 2/3] examples/l2fwd: Handle SIGINT and SIGTERM in l2fwd
Handle SIGINT and SIGTERM in l2fwd.
Signed-off-by: Zhihong Wang
Acked-by: Michael Qiu
---
examples/l2fwd/main.c | 161 +++---
1 file changed, 139 insertions(+), 22 deletions(-)
diff --git a/examples/l2fwd/main.c b/examples/l2fwd/main.c
index 720fd5a..9a6f80b 100644
--- a/examples/l2fwd/main.c
+++ b/examples/l2fwd/main.c
@@ -44,6 +44,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -69,6 +72,16 @@
#include
#include
+#define PORT_IDLE 0
+#define PORT_INIT 1
+#define PORT_WORK 2
+#define PORT_STOP 3
+#define PORT_QUIT 4
+
+static volatile uint32_t port_status;
+static volatile bool force_quit;
+static volatile int signo_quit;
+
#define RTE_LOGTYPE_L2FWD RTE_LOGTYPE_USER1
#define NB_MBUF 8192
@@ -283,8 +296,7 @@ l2fwd_main_loop(void)
portid);
}
- while (1) {
-
+ while (!force_quit) {
cur_tsc = rte_rdtsc();
/*
@@ -491,8 +503,12 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
port_mask)
printf("\nChecking link status");
fflush(stdout);
for (count = 0; count <= MAX_CHECK_TIME; count++) {
+ if (force_quit)
+ return;
all_ports_up = 1;
for (portid = 0; portid < port_num; portid++) {
+ if (force_quit)
+ return;
if ((port_mask & (1 << portid)) == 0)
continue;
memset(&link, 0, sizeof(link));
@@ -534,18 +550,110 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
port_mask)
}
}
+static uint8_t
+start_ports(void)
+{
+ unsigned portid, nb_ports, avail_ports;
+ int ret;
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_IDLE, PORT_INIT) == 0) {
+ printf("Ports not idle...\n");
+ return 0;
+ }
+
+ nb_ports = rte_eth_dev_count();
+ avail_ports = 0;
+ for (portid = 0; portid < nb_ports; portid++) {
+ if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ avail_ports++;
+ printf("Starting port %d...", portid);
+ ret = rte_eth_dev_start(portid);
+ if (ret < 0)
+ rte_exit(EXIT_FAILURE,
+ "rte_eth_dev_start:err=%d, port=%u\n",
+ ret, (unsigned) portid);
+ rte_eth_promiscuous_enable(portid);
+ printf(" Done\n");
+ }
+
+ if (avail_ports) {
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_INIT, PORT_WORK) == 0)
+ printf("Set port state failed!\n");
+ } else {
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_INIT, PORT_IDLE) == 0)
+ printf("Set port state failed!\n");
+ }
+
+ return avail_ports;
+}
+
+static void
+stop_ports(void)
+{
+ unsigned portid, nb_ports;
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_WORK, PORT_STOP) == 0) {
+ printf("Ports not started...\n");
+ return;
+ }
+
+ nb_ports = rte_eth_dev_count();
+ for (portid = 0; portid < nb_ports; portid++) {
+ if ((l2fwd_enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ printf("Stopping port %d...", portid);
+ rte_eth_dev_stop(portid);
+ rte_eth_dev_close(portid);
+ printf(" Done\n");
+ }
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_STOP, PORT_IDLE) == 0)
+ printf("Set port state failed!\n");
+}
+
+static void
+signal_handler(int signum)
+{
+ if (signum == SIGINT || signum == SIGTERM) {
+ printf("\nSignal %d received, preparing to exit...\n",
+ signum);
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_IDLE, PORT_QUIT) == 0) {
+ printf("Ports started already...\n");
+ signo_quit = signum;
+ force_quit = true;
+ } else {
+ printf("Ports not started yet...\n");
+ printf("Bye...\n");
+ /* exit with the expected status */
+ signal(signum, SIG_DFL);
+ kill(getpid(), signum);
+ }
+ }
+}
+
int
main(int argc, char **argv)
{
struct lcore_queue_conf *qconf;
struct rte_eth_dev_info dev_info;
int ret;
- uint8_t nb_ports;
- uint8_t nb_ports_available;
+ uint8_t nb_ports, avail_po
[dpdk-dev] [PATCH v4 3/3] examples/l3fwd: Handle SIGINT and SIGTERM in l3fwd
Handle SIGINT and SIGTERM in l3fwd.
Signed-off-by: Zhihong Wang
Acked-by: Michael Qiu
---
examples/l3fwd/main.c | 167 +++---
1 file changed, 145 insertions(+), 22 deletions(-)
diff --git a/examples/l3fwd/main.c b/examples/l3fwd/main.c
index 5b0c2dd..f73d2a4 100644
--- a/examples/l3fwd/main.c
+++ b/examples/l3fwd/main.c
@@ -41,6 +41,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -75,6 +78,16 @@
#include
#include
+#define PORT_IDLE 0
+#define PORT_INIT 1
+#define PORT_WORK 2
+#define PORT_STOP 3
+#define PORT_QUIT 4
+
+static volatile uint32_t port_status;
+static volatile bool force_quit;
+static volatile int signo_quit;
+
#define APP_LOOKUP_EXACT_MATCH 0
#define APP_LOOKUP_LPM 1
#define DO_RFC_1812_CHECKS
@@ -1553,8 +1566,7 @@ main_loop(__attribute__((unused)) void *dummy)
portid, queueid);
}
- while (1) {
-
+ while (!force_quit) {
cur_tsc = rte_rdtsc();
/*
@@ -2516,8 +2528,12 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
port_mask)
printf("\nChecking link status");
fflush(stdout);
for (count = 0; count <= MAX_CHECK_TIME; count++) {
+ if (force_quit)
+ return;
all_ports_up = 1;
for (portid = 0; portid < port_num; portid++) {
+ if (force_quit)
+ return;
if ((port_mask & (1 << portid)) == 0)
continue;
memset(&link, 0, sizeof(link));
@@ -2559,6 +2575,101 @@ check_all_ports_link_status(uint8_t port_num, uint32_t
port_mask)
}
}
+static uint8_t
+start_ports(void)
+{
+ unsigned portid, nb_ports, avail_ports;
+ int ret;
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_IDLE, PORT_INIT) == 0) {
+ printf("Ports not idle...\n");
+ return 0;
+ }
+
+ nb_ports = rte_eth_dev_count();
+ avail_ports = 0;
+ for (portid = 0; portid < nb_ports; portid++) {
+ if ((enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ avail_ports++;
+ printf("Starting port %d...", portid);
+ ret = rte_eth_dev_start(portid);
+ if (ret < 0)
+ rte_exit(EXIT_FAILURE,
+ "rte_eth_dev_start: err=%d, port=%d\n",
+ ret, portid);
+ /*
+* If enabled, put device in promiscuous mode.
+* This allows IO forwarding mode to forward packets
+* to itself through 2 cross-connected ports of the
+* target machine.
+*/
+ if (promiscuous_on)
+ rte_eth_promiscuous_enable(portid);
+ printf(" Done\n");
+ }
+
+ if (avail_ports) {
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_INIT, PORT_WORK) == 0)
+ printf("Set port state failed!\n");
+ } else {
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_INIT, PORT_IDLE) == 0)
+ printf("Set port state failed!\n");
+ }
+
+ return avail_ports;
+}
+
+static void
+stop_ports(void)
+{
+ unsigned portid, nb_ports;
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_WORK, PORT_STOP) == 0) {
+ printf("Ports not started...\n");
+ return;
+ }
+
+ nb_ports = rte_eth_dev_count();
+ for (portid = 0; portid < nb_ports; portid++) {
+ if ((enabled_port_mask & (1 << portid)) == 0)
+ continue;
+ printf("Stopping port %d...", portid);
+ rte_eth_dev_stop(portid);
+ rte_eth_dev_close(portid);
+ printf(" Done\n");
+ }
+
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_STOP, PORT_IDLE) == 0)
+ printf("Set port state failed!\n");
+}
+
+static void
+signal_handler(int signum)
+{
+ if (signum == SIGINT || signum == SIGTERM) {
+ printf("\nSignal %d received, preparing to exit...\n",
+ signum);
+ if (rte_atomic32_cmpset(&port_status,
+ PORT_IDLE, PORT_QUIT) == 0) {
+ printf("Ports started already...\n");
+ signo_quit = signum;
+ force_quit = true;
+ } else {
+ printf("Ports not started yet...\n");
+ printf("Bye...\n");
+ /* exit with the e
