[dpdk-dev] [PATCH] net/ixgbe: fix vlan insert parameter type and its use
Hi Bernard,
> -Original Message-
> From: Iremonger, Bernard
> Sent: Wednesday, October 19, 2016 6:56 PM
> To: Lu, Wenzhuo; E. Scott Daniels; Zhang, Helin
> Cc: dev at dpdk.org; az5157 at att.com
> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: fix vlan insert parameter type and
> its
> use
>
> Hi Wenzhuo, Scott,
>
>
>
> > > Subject: [dpdk-dev] [PATCH] net/ixgbe: fix vlan insert parameter
> > > type and its use
> > >
> > > The final parameter to rte_pmd_ixgbe_set_vf_vlan_insert is uint8_t
> > > and treated as a binary flag when it needs to be a uint16_t and
> > > treated as a VLAN id. The data sheet (sect 8.2.3.27.13) describes
> > > the right most
> > > 16 bits as the VLAN id that is to be inserted; the
> > > 16.11 code is accepting only a 1 or 0 thus effectively only
> > > allowing the VLAN id 1 to be inserted (0 disables the insertion setting).
> > >
> > > This patch changes the final parm name to represent the data that is
> > > being accepted (vlan_id), changes the type to permit all valid VLAN
> > > ids, and validates the parameter based on the range of 0 to 4095.
> > > Corresponding changes to prototype and documentation in the .h file.
> > >
> > > Fixes: 49e248223e9f71 ("net/ixgbe: add API for VF management")
> > >
> > > Signed-off-by: E. Scott Daniels
> > > ---
> > > drivers/net/ixgbe/ixgbe_ethdev.c | 8
> > > drivers/net/ixgbe/rte_pmd_ixgbe.h | 9 +
> > > 2 files changed, 9 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > index 4ca5747..316af73 100644
> > > --- a/drivers/net/ixgbe/ixgbe_ethdev.c
> > > +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
> > > @@ -4727,7 +4727,7 @@ rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t
> > > port, uint16_t vf, uint8_t on) }
> > >
> > > int
> > > -rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf, uint8_t
> > > on)
> > > +rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf,
> > > +uint16_t
> > > +vlan_id)
> > > {
> > > struct ixgbe_hw *hw;
> > > uint32_t ctrl;
> > > @@ -4742,13 +4742,13 @@ rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t
> > port,
> > > uint16_t vf, uint8_t on)
> > > if (vf >= dev_info.max_vfs)
> > > return -EINVAL;
> > >
> > > - if (on > 1)
> > > + if (vlan_id > 4095)
> > > return -EINVAL;
> > >
> > > hw = IXGBE_DEV_PRIVATE_TO_HW(dev->data->dev_private);
> > > ctrl = IXGBE_READ_REG(hw, IXGBE_VMVIR(vf));
> > > - if (on) {
> > > - ctrl = on;
> > > + if (vlan_id) {
> > > + ctrl = vlan_id;
> > I believe this patch is a good idea of an enhancement. But you cannot
> > leverage the existing code like this.
> > The register IXGBE_VMVIR is only for enable/disable. We cannot write
> > the VLAN ID into it.
> > If you want to merge the 2 things, enabling/disabling and setting VLAN
> > ID together. I think we need a totally new implementation. So NACK.
>
> Reading the 82599 data sheet (sect 8.2.3.27.13), the change from Scott is
> correct.
> The NACK is not correct.
You're right. I made a mistake about the words 'default vlan'. It's not fixed
but the value of 'Port VLAN ID'.
So the previous patch is not good, we need to fix it. Thanks for correcting me.
>
> However changing the API means that where it is called needs to be changed
> too.
> It is called at present from app/testpmd/cmdline.c line 4731.
>
>
>
> > > ctrl |= IXGBE_VMVIR_VLANA_DEFAULT;
> > > } else {
> > > ctrl = 0;
> > > diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > > b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > > index 2fdf530..c2fb826 100644
> > > --- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > > +++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
> > > @@ -99,16 +99,17 @@ int rte_pmd_ixgbe_set_vf_mac_anti_spoof(uint8_t
> > > port, uint16_t vf, uint8_t on);
> > > *The port identifier of the Ethernet device.
> > > * @param vf
> > > *ID specifying VF.
> > > - * @param on
> > > - *1 - Enable VF's vlan insert.
> > > - *0 - Disable VF's vlan insert
> > > + * @param vlan_id
> > > + *0 - Disable VF's vlan insert.
> > > + *n - Enable; n is inserted as the vlan id.
> > > *
> > > * @return
> > > * - (0) if successful.
> > > * - (-ENODEV) if *port* invalid.
> > > * - (-EINVAL) if bad parameter.
> > > */
> > > -int rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf,
> > > uint8_t on);
> > > +int rte_pmd_ixgbe_set_vf_vlan_insert(uint8_t port, uint16_t vf,
> > > + uint16_t vlan_id);
> > >
> > > /**
> > > * Enable/Disable tx loopback
> > > --
> > > 1.9.1
>
> Regards,
>
> Bernard.
[dpdk-dev] [PATCH v2 0/2] net/ixgbe: fix VF VLAN insert
Hi, > -Original Message- > From: Iremonger, Bernard > Sent: Wednesday, October 19, 2016 10:48 PM > To: dev at dpdk.org; daniels at research.att.com; Lu, Wenzhuo; az5157 at > att.com > Cc: Iremonger, Bernard > Subject: [PATCH v2 0/2] net/ixgbe: fix VF VLAN insert > > Changes in v2: > Add testpmd patch. > Update testpmd for change to rte_pmd_ixgbe_set_vf_vlan_insert function. > > Bernard Iremonger (1): > app/test_pmd: change to the VF VLAN insert command > > E. Scott Daniels (1): > net/ixgbe: fix VLAN insert parameter type and its use > > app/test-pmd/cmdline.c | 19 +-- > doc/guides/testpmd_app_ug/testpmd_funcs.rst | 2 +- > drivers/net/ixgbe/ixgbe_ethdev.c| 8 > drivers/net/ixgbe/rte_pmd_ixgbe.h | 9 + > 4 files changed, 19 insertions(+), 19 deletions(-) > > -- > 2.10.1 Series-Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH v5 1/2] net/ixgbe: support multiqueue mode VMDq DCB with SRIOV
Hi, > -Original Message- > From: Iremonger, Bernard > Sent: Wednesday, October 19, 2016 6:21 PM > To: dev at dpdk.org; Shah, Rahul R; Lu, Wenzhuo > Cc: Iremonger, Bernard > Subject: [PATCH v5 1/2] net/ixgbe: support multiqueue mode VMDq DCB with > SRIOV > > Modify ixgbe_check_mq_mode function, > when SRIOV is enabled, enable mq_mode > ETH_MQ_RX_VMDQ_DCB and ETH_MQ_TX_VMDQ_DCB. > > Modify ixgbe_dcb_tx_hw_config function, > replace the struct ixgbe_hw parameter with a struct rte_eth_dev parameter and > handle SRIOV enabled. > > Modify ixgbe_dev_mq_rx_configure function, when SRIOV is enabled, enable > mq_mode ETH_MQ_RX_VMDQ_DCB. > > Modify ixgbe_configure_dcb function, > drop check on dev->data->nb_rx_queues. > > Signed-off-by: Rahul R Shah > Signed-off-by: Bernard Iremonger Acked-by: Wenzhuo Lu
[dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on list
Hi Scott, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of E. Scott Daniels > Sent: Thursday, October 20, 2016 6:23 AM > To: Zhang, Helin; Iremonger, Bernard > Cc: dev at dpdk.org; az5157 at att.com; E. Scott Daniels > Subject: [dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on list > > This change prevents the attempt to add a structure which is already on the > callback list. If a struct with matching parameters is found on the list, > then no > action is taken. If a struct with matching parameters is found on the list, > then no > action is taken. > > Signed-off-by: E. Scott Daniels I think the fix itself is good. But 2 things, 1, normally we don't create a cover letter for a patch set which only has one patch. Just sending the patch itself is enough. 2, ' net/ixgbe: ' in the title is used to describe the component. So the title should be ' lib/ether: prevent duplicate callback on list'. Thanks.
[dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on list
Hi Scott, > -Original Message- > From: Scott Daniels [mailto:daniels at research.att.com] > Sent: Thursday, October 20, 2016 10:11 AM > To: Lu, Wenzhuo > Cc: Zhang, Helin; Iremonger, Bernard; dev at dpdk.org; ZELEZNIAK, ALEX > Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on list > > > > On Wed, 19 Oct 2016, Lu, Wenzhuo wrote: > > > Hi Scott, > > > >> -Original Message- > >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of E. Scott Daniels > >> Sent: Thursday, October 20, 2016 6:23 AM > >> To: Zhang, Helin; Iremonger, Bernard > >> Cc: dev at dpdk.org; az5157 at att.com; E. Scott Daniels > >> Subject: [dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on > >> list > >> > >> This change prevents the attempt to add a structure which is already > >> on the callback list. If a struct with matching parameters is found > >> on the list, then no action is taken. If a struct with matching > >> parameters is found on the list, then no action is taken. > >> > >> Signed-off-by: E. Scott Daniels > > I think the fix itself is good. But 2 things, 1, normally we don't > > create a cover letter for a patch set which only has one patch. Just > > sending the > patch itself is enough. > > 2, ' net/ixgbe: ' in the title is used to describe the component. So the > > title > should be ' lib/ether: prevent duplicate callback on list'. > > Thanks. > > Thanks for the advice. My mistake on the component. Is there an easy way to > fix, or does it make sense just to nack this and I'll submit one with the > correct > component. No need to NACK it. You can send a V2 with the correct component. And I think you can add my ack in the V2. Acked-by: Wenzhuo Lu BTW, I forgot to mention that as it's a fix. We always add a Fixes tag in the commit log. You can find the example from other one's mails :) > > Scott > > > > >
[dpdk-dev] [PATCH V2 2/2] virtio: support IOMMU platform
On 2016?10?07? 12:24, Michael S. Tsirkin wrote: > On Wed, Sep 28, 2016 at 04:25:12PM +0800, Jason Wang wrote: >> Negotiate VIRTIO_F_IOMMU_PLATFORM to have IOMMU support. >> >> Signed-off-by: Jason Wang >> --- >> Changes from v1: >> - remove unnecessary NEED_MAPPING flag > One thing we probably should do is enable this flag > with VFIO but not with UIO or VFIO-noiommu. Sounds good, will try do it in next version. >> --- >> drivers/net/virtio/virtio_ethdev.h | 3 ++- >> drivers/net/virtio/virtio_pci.h| 3 ++- >> 2 files changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/net/virtio/virtio_ethdev.h >> b/drivers/net/virtio/virtio_ethdev.h >> index 2ecec6e..04a06e2 100644 >> --- a/drivers/net/virtio/virtio_ethdev.h >> +++ b/drivers/net/virtio/virtio_ethdev.h >> @@ -63,7 +63,8 @@ >> 1u << VIRTIO_NET_F_CTRL_RX | \ >> 1u << VIRTIO_NET_F_CTRL_VLAN | \ >> 1u << VIRTIO_NET_F_MRG_RXBUF | \ >> - 1ULL << VIRTIO_F_VERSION_1) >> + 1ULL << VIRTIO_F_VERSION_1 | \ >> + 1ULL << VIRTIO_F_IOMMU_PLATFORM ) > Space before ) looks kind of ugly. Will fix this. > >> >> /* >>* CQ function prototype >> diff --git a/drivers/net/virtio/virtio_pci.h >> b/drivers/net/virtio/virtio_pci.h >> index 3430a39..0aa0015 100644 >> --- a/drivers/net/virtio/virtio_pci.h >> +++ b/drivers/net/virtio/virtio_pci.h >> @@ -138,6 +138,7 @@ struct virtnet_ctl; >> #define VIRTIO_RING_F_INDIRECT_DESC28 >> >> #define VIRTIO_F_VERSION_1 32 >> +#define VIRTIO_F_IOMMU_PLATFORM 33 >> >> /* >>* Some VirtIO feature bits (currently bits 28 through 31) are >> @@ -145,7 +146,7 @@ struct virtnet_ctl; >>* rest are per-device feature bits. >>*/ >> #define VIRTIO_TRANSPORT_F_START 28 >> -#define VIRTIO_TRANSPORT_F_END 32 >> +#define VIRTIO_TRANSPORT_F_END 34 >> > This seems unused. Drop it? Ok. > >> /* The Guest publishes the used index for which it expects an interrupt >>* at the end of the avail ring. Host should ignore the avail->flags >> field. */ >> -- >> 2.7.4
[dpdk-dev] [PATCH] net/i40e: fix Rx hang when disable LLDP
Disabling LLDP result in the device firmware
not configuring the receive packet buffer, this
possibly causing a receive hang.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Signed-off-by: Qi Zhang
---
drivers/net/i40e/i40e_ethdev.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5af0e43..08e4049 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1215,11 +1215,6 @@ eth_i40e_dev_uninit(struct rte_eth_dev *dev)
dev->rx_pkt_burst = NULL;
dev->tx_pkt_burst = NULL;
- /* Disable LLDP */
- ret = i40e_aq_stop_lldp(hw, true, NULL);
- if (ret != I40E_SUCCESS) /* Its failure can be ignored */
- PMD_INIT_LOG(INFO, "Failed to stop lldp");
-
/* Clear PXE mode */
i40e_clear_pxe_mode(hw);
@@ -9385,10 +9380,6 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool
sw_dcb)
* LLDP MIB change event.
*/
if (sw_dcb == TRUE) {
- ret = i40e_aq_stop_lldp(hw, TRUE, NULL);
- if (ret != I40E_SUCCESS)
- PMD_INIT_LOG(DEBUG, "Failed to stop lldp");
-
ret = i40e_init_dcb(hw);
/* if sw_dcb, lldp agent is stopped, the return from
* i40e_init_dcb we expect is failure with I40E_AQ_RC_EPERM
--
2.7.4
[dpdk-dev] [PATCH v2] net/i40e: fix Rx hang when disable LLDP
Remove stopping LLDP as a workaround for a known
errata which can cause Rx hang.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
Signed-off-by: Qi Zhang
---
v2:
- more correct commit log.
drivers/net/i40e/i40e_ethdev.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 5af0e43..08e4049 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1215,11 +1215,6 @@ eth_i40e_dev_uninit(struct rte_eth_dev *dev)
dev->rx_pkt_burst = NULL;
dev->tx_pkt_burst = NULL;
- /* Disable LLDP */
- ret = i40e_aq_stop_lldp(hw, true, NULL);
- if (ret != I40E_SUCCESS) /* Its failure can be ignored */
- PMD_INIT_LOG(INFO, "Failed to stop lldp");
-
/* Clear PXE mode */
i40e_clear_pxe_mode(hw);
@@ -9385,10 +9380,6 @@ i40e_dcb_init_configure(struct rte_eth_dev *dev, bool
sw_dcb)
* LLDP MIB change event.
*/
if (sw_dcb == TRUE) {
- ret = i40e_aq_stop_lldp(hw, TRUE, NULL);
- if (ret != I40E_SUCCESS)
- PMD_INIT_LOG(DEBUG, "Failed to stop lldp");
-
ret = i40e_init_dcb(hw);
/* if sw_dcb, lldp agent is stopped, the return from
* i40e_init_dcb we expect is failure with I40E_AQ_RC_EPERM
--
2.7.4
[dpdk-dev] [PATCH V2 2/2] virtio: support IOMMU platform
On 2016?10?11? 12:14, Yuanhan Liu wrote: > On Fri, Oct 07, 2016 at 07:24:44AM +0300, Michael S. Tsirkin wrote: >> On Wed, Sep 28, 2016 at 04:25:12PM +0800, Jason Wang wrote: >>> Negotiate VIRTIO_F_IOMMU_PLATFORM to have IOMMU support. >>> >>> Signed-off-by: Jason Wang >>> --- >>> Changes from v1: >>> - remove unnecessary NEED_MAPPING flag >> One thing we probably should do is enable this flag >> with VFIO but not with UIO or VFIO-noiommu. > Good suggestion. I think we could do that in another patch. Yes. > >>> --- >>> drivers/net/virtio/virtio_ethdev.h | 3 ++- >>> drivers/net/virtio/virtio_pci.h| 3 ++- >>> 2 files changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/net/virtio/virtio_ethdev.h >>> b/drivers/net/virtio/virtio_ethdev.h >>> index 2ecec6e..04a06e2 100644 >>> --- a/drivers/net/virtio/virtio_ethdev.h >>> +++ b/drivers/net/virtio/virtio_ethdev.h >>> @@ -63,7 +63,8 @@ >>> 1u << VIRTIO_NET_F_CTRL_RX | \ >>> 1u << VIRTIO_NET_F_CTRL_VLAN | \ >>> 1u << VIRTIO_NET_F_MRG_RXBUF | \ >>> -1ULL << VIRTIO_F_VERSION_1) >>> +1ULL << VIRTIO_F_VERSION_1 | \ >>> +1ULL << VIRTIO_F_IOMMU_PLATFORM ) >> Space before ) looks kind of ugly. > Yes, a bit. I will remove it while apply. > >>> #define VIRTIO_TRANSPORT_F_START 28 >>> -#define VIRTIO_TRANSPORT_F_END 32 >>> +#define VIRTIO_TRANSPORT_F_END 34 >>> >> This seems unused. Drop it? > Indeed. I will submit a patch to remove both (_START and _END). > > --yliu Thanks
[dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the packet
Hello Konstantin, > > My vote also would be to have timestamp in the second cache line. > About moving seqn to the 2-nd cache line too - that's probably a fair point. It may impact throughput till ~6% for applications required such embedded Timestamps. > About the rest of the patch: > Do you really need to put that code into the PMDs itself? > Can't the same result be achieved by using RX callbacks? > Again that approach would work with any PMD and there would be no need > to modify PMD code itself. Correct, the approach with using callbacs (rte_eth_timesync_read_[r|t]x_timestamp()) Has also some Cons for this use case: - FSI needs the most accurate stamping as possible by reasons were described in Cover letter - callback will be called from user app and so you have to take into account Difference between time when packet was released by NIC and callback call - such difference is not easy to estimate correctly due to dependency on CPU type, Its frequency and current load conditions - even estimated it would be hard without additional performance penalty to align Packet with timestamp, taking account that call may actually placed from Different thread or even process. It looks the least impacting and correct way is to have timestamp in rte_mbuf and fill It in Rx burst procedure. > Another thing, that I am in doubt why to use system time? > Wouldn't raw HW TSC value (rte_rdtsc()) do here? System time is being used for periodic clock synchronization between wall clock and NIC to estimate NIC clock deviation. It is in assumption the system itself is synchronized by PTP from master clock. It is run on context of control thread. Thanks, Oleg.
[dpdk-dev] [PATCH] [RFC] Elastic Flow Distributor
The following RFC shows the functionality and usage overview of
the new Elastic Flow Distributor (EFD) library.
Library code is included in the RFC (implemention in progress, API complete),
with a sample application to demonstrate the usage of the library,
based on the existing server/client sample app.
A PDF document has been uploaded with the following and more information
about the library, including color images (not ascii) to improve
readability, in the following link:
https://github.com/pablodelara/perfect_hash_flow_distributor/blob/master/EFD_description.pdf
Introduction
In Data Centers today clustering and scheduling of distributed workloads is a
very common task. Many workload requires a deterministic partitioning of a flat
key space among a cluster of machines. When a packet enters the cluster, the
ingress node will direct the packet to its handling node. For example,
datacenters with disaggregated storage uses storage metadata table to forward
I/O requests to correct backend storage cluster, stateful packet inspection will
use match incoming flows to signatures in flow tables to send incoming packets
to their intended deep packet inspection (DPI) devices, and so on.
EFD is a distributor library that uses perfect hashing to determine a
target/value for a given incoming flow key. It has the following advantages:
first, because it uses perfect hashing it does not store the key itself and
hence lookup performance is not dependent on the key size. Second, the
target/value can be any arbitrary value hence the system designer and/or
operator can better optimize service rates and inter-cluster network traffic
locating. Third, since the storage requirement is much smaller than a
hash-based flow table (i.e. better fit for CPU cache), EFD can scale to millions
of flow keys. Finally, with current optimized library implementation performance
is fully scalable with number of CPU cores.
Overview
The basic idea of EFD is when a given key is to be inserted, a family of hash
functions is searched until the correct hash function that maps the input key to
the correct value is found. However, rather than explicitly storing all keys and
their associated values, EFD stores only indices of hash functions that map keys
to values, and thereby consumes much less space than conventional flow-based
tables. The lookup operation is very simple, similar to computational-based
scheme, given an input key the lookup operation is reduced to hashing that key
with the correct hash function.
Intuitively, finding a hash function that maps each of a large number (millions)
of input keys to the correct output value is effectively impossible, as a result
EFD, breaks the problem into smaller pieces (divide and conquer). EFD divides
the entire input key set into many small groups. Each group consists of
approximately 20-28 keys (a configurable parameter for the library), then, for
each small group, a brute force search to find a hash function that produces the
correct outputs for each key in the group.
It should be mentioned that since in the online lookup table for EFD doesn?t
store the key itself, the size of the EFD table is independent of the key size
and hence EFD lookup performance which is almost constant irrespective of the
length of the key which is a highly desirable feature especially for longer
keys.
API
===
The EFD library API is created with a very similar semantics of a hash-index or
a flow table, the application creates an EFD table for a given maximum number of
flows, a function is called to insert a flow key with a specific target value,
and another function is used to retrieve target values for a given individual
flow key or a bulk of keys.
EFD Table Create
The function rte_efd_create("flow table", num_flows, online_socket_bitmask,
offline_socket_bitmask) is used to create and return a pointer to an EFD table
that is sized to hold up to num_flows key. The online version of the EFD table
(the one that does not store the keys and is used for lookups) will be allocated
and created in the last level cache (LLC) of the socket defined by the
online_socket_bitmask, while the offline EFD table (the one that stores the keys
and is used for key inserts and for computing the perfect hashing) is allocated
and created in the LLC of the socket defined by offline_socket_bitmask. It
should be noted, that For highest performance the socket id should match that
where the thread is running, i.e. the online EFD lookup table should be created
on the same socket as where the lookup thread is running.
EFD Insert and Update
-
The EFD function to insert a key or update a key to a new value is
rte_efd_update(struct rte_efd_table *table, unsigned socket_id, const efd_key_t
*key, efd_value_t value). This function will update an existing key to a new
value (target) if the key has already been inserted before, or will insert the
pair if this key has not been inserted before
[dpdk-dev] [PATCH 1/2] drivers: add name alias registration for rte_driver
This adds infrastructure for drivers to allow being requested by an alias
so that a renamed driver can still get loaded by its legacy name.
Signed-off-by: Jan Blunck
---
lib/librte_eal/common/eal_common_vdev.c | 8
lib/librte_eal/common/include/rte_dev.h | 1 +
lib/librte_eal/common/include/rte_vdev.h | 5 +
3 files changed, 14 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_vdev.c
b/lib/librte_eal/common/eal_common_vdev.c
index 8b05f50..0ff2377 100644
--- a/lib/librte_eal/common/eal_common_vdev.c
+++ b/lib/librte_eal/common/eal_common_vdev.c
@@ -79,6 +79,14 @@ rte_eal_vdev_init(const char *name, const char *args)
return driver->probe(name, args);
}
+ /* Give new names precedence over aliases. */
+ TAILQ_FOREACH(driver, &vdev_driver_list, next) {
+ if (driver->driver.alias &&
+ !strncmp(driver->driver.alias, name,
+ strlen(driver->driver.alias)))
+ return driver->probe(name, args);
+ }
+
RTE_LOG(ERR, EAL, "no driver found for %s\n", name);
return -EINVAL;
}
diff --git a/lib/librte_eal/common/include/rte_dev.h
b/lib/librte_eal/common/include/rte_dev.h
index b3873bd..8840380 100644
--- a/lib/librte_eal/common/include/rte_dev.h
+++ b/lib/librte_eal/common/include/rte_dev.h
@@ -149,6 +149,7 @@ void rte_eal_device_remove(struct rte_device *dev);
struct rte_driver {
TAILQ_ENTRY(rte_driver) next; /**< Next in list. */
const char *name; /**< Driver name. */
+ const char *alias; /**< Driver alias. */
};
/**
diff --git a/lib/librte_eal/common/include/rte_vdev.h
b/lib/librte_eal/common/include/rte_vdev.h
index 97260b2..ee5060e 100644
--- a/lib/librte_eal/common/include/rte_vdev.h
+++ b/lib/librte_eal/common/include/rte_vdev.h
@@ -83,13 +83,18 @@ void rte_eal_vdrv_unregister(struct rte_vdev_driver
*driver);
#define RTE_PMD_REGISTER_VDEV(nm, vdrv)\
RTE_INIT(vdrvinitfn_ ##vdrv);\
+static const char * vdrvinit_ ## nm ## _alias;\
static void vdrvinitfn_ ##vdrv(void)\
{\
(vdrv).driver.name = RTE_STR(nm);\
+ (vdrv).driver.alias = vdrvinit_ ## nm ## _alias;\
rte_eal_vdrv_register(&vdrv);\
} \
RTE_PMD_EXPORT_NAME(nm, __COUNTER__)
+#define RTE_PMD_REGISTER_ALIAS(nm, alias)\
+static const char * vdrvinit_ ## nm ## _alias = RTE_STR(alias)
+
#ifdef __cplusplus
}
#endif
--
2.6.6
[dpdk-dev] [PATCH 2/2] drivers: register aliases for renamed VDEV drivers
This registers the legacy names of the driver being renamed in commit
2f45703c17acb943aaded9f79676fd56a72542b2.
Signed-off-by: Jan Blunck
---
drivers/net/af_packet/rte_eth_af_packet.c | 1 +
drivers/net/bonding/rte_eth_bond_pmd.c| 1 +
drivers/net/mpipe/mpipe_tilegx.c | 2 ++
drivers/net/null/rte_eth_null.c | 1 +
drivers/net/pcap/rte_eth_pcap.c | 1 +
drivers/net/ring/rte_eth_ring.c | 1 +
drivers/net/vhost/rte_eth_vhost.c | 1 +
drivers/net/virtio/virtio_user_ethdev.c | 1 +
drivers/net/xenvirt/rte_eth_xenvirt.c | 1 +
9 files changed, 10 insertions(+)
diff --git a/drivers/net/af_packet/rte_eth_af_packet.c
b/drivers/net/af_packet/rte_eth_af_packet.c
index 201c1be..ff45068 100644
--- a/drivers/net/af_packet/rte_eth_af_packet.c
+++ b/drivers/net/af_packet/rte_eth_af_packet.c
@@ -895,6 +895,7 @@ static struct rte_vdev_driver pmd_af_packet_drv = {
};
RTE_PMD_REGISTER_VDEV(net_af_packet, pmd_af_packet_drv);
+RTE_PMD_REGISTER_ALIAS(net_af_packet, eth_af_packet);
RTE_PMD_REGISTER_PARAM_STRING(net_af_packet,
"iface= "
"qpairs= "
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 9e38ec9..9df245e 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -2560,6 +2560,7 @@ static struct rte_vdev_driver bond_drv = {
};
RTE_PMD_REGISTER_VDEV(net_bonding, bond_drv);
+RTE_PMD_REGISTER_ALIAS(net_bonding, eth_bond);
RTE_PMD_REGISTER_PARAM_STRING(net_bonding,
"slave= "
diff --git a/drivers/net/mpipe/mpipe_tilegx.c b/drivers/net/mpipe/mpipe_tilegx.c
index adf299b..f00 100644
--- a/drivers/net/mpipe/mpipe_tilegx.c
+++ b/drivers/net/mpipe/mpipe_tilegx.c
@@ -1632,7 +1632,9 @@ static struct rte_vdev_driver pmd_mpipe_gbe_drv = {
};
RTE_PMD_REGISTER_VDEV(net_mpipe_xgbe, pmd_mpipe_xgbe_drv);
+RTE_PMD_REGISTER_ALIAS(net_mpipe_xgbe, xgbe);
RTE_PMD_REGISTER_VDEV(net_mpipe_gbe, pmd_mpipe_gbe_drv);
+RTE_PMD_REGISTER_ALIAS(net_mpipe_gbe, gbe);
static void __attribute__((constructor, used))
mpipe_init_contexts(void)
diff --git a/drivers/net/null/rte_eth_null.c b/drivers/net/null/rte_eth_null.c
index 0b7cc37..836d982 100644
--- a/drivers/net/null/rte_eth_null.c
+++ b/drivers/net/null/rte_eth_null.c
@@ -692,6 +692,7 @@ static struct rte_vdev_driver pmd_null_drv = {
};
RTE_PMD_REGISTER_VDEV(net_null, pmd_null_drv);
+RTE_PMD_REGISTER_ALIAS(net_null, eth_null);
RTE_PMD_REGISTER_PARAM_STRING(net_null,
"size= "
"copy=");
diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
index 0c4711d..0162f44 100644
--- a/drivers/net/pcap/rte_eth_pcap.c
+++ b/drivers/net/pcap/rte_eth_pcap.c
@@ -1065,6 +1065,7 @@ static struct rte_vdev_driver pmd_pcap_drv = {
};
RTE_PMD_REGISTER_VDEV(net_pcap, pmd_pcap_drv);
+RTE_PMD_REGISTER_ALIAS(net_pcap, eth_pcap);
RTE_PMD_REGISTER_PARAM_STRING(net_pcap,
ETH_PCAP_RX_PCAP_ARG "= "
ETH_PCAP_TX_PCAP_ARG "= "
diff --git a/drivers/net/ring/rte_eth_ring.c b/drivers/net/ring/rte_eth_ring.c
index ee1fb76..6d2a8c1 100644
--- a/drivers/net/ring/rte_eth_ring.c
+++ b/drivers/net/ring/rte_eth_ring.c
@@ -629,5 +629,6 @@ static struct rte_vdev_driver pmd_ring_drv = {
};
RTE_PMD_REGISTER_VDEV(net_ring, pmd_ring_drv);
+RTE_PMD_REGISTER_ALIAS(net_ring, eth_ring);
RTE_PMD_REGISTER_PARAM_STRING(net_ring,
ETH_RING_NUMA_NODE_ACTION_ARG "=name:node:action(ATTACH|CREATE)");
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 6f58476..766d4ef 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -1244,6 +1244,7 @@ static struct rte_vdev_driver pmd_vhost_drv = {
};
RTE_PMD_REGISTER_VDEV(net_vhost, pmd_vhost_drv);
+RTE_PMD_REGISTER_ALIAS(net_vhost, eth_vhost);
RTE_PMD_REGISTER_PARAM_STRING(net_vhost,
"iface= "
"queues=");
diff --git a/drivers/net/virtio/virtio_user_ethdev.c
b/drivers/net/virtio/virtio_user_ethdev.c
index bfdc3d0..406beea 100644
--- a/drivers/net/virtio/virtio_user_ethdev.c
+++ b/drivers/net/virtio/virtio_user_ethdev.c
@@ -479,6 +479,7 @@ static struct rte_vdev_driver virtio_user_driver = {
};
RTE_PMD_REGISTER_VDEV(net_virtio_user, virtio_user_driver);
+RTE_PMD_REGISTER_ALIAS(net_virtio_user, virtio_user);
RTE_PMD_REGISTER_PARAM_STRING(net_virtio_user,
"path= "
"mac= "
diff --git a/drivers/net/xenvirt/rte_eth_xenvirt.c
b/drivers/net/xenvirt/rte_eth_xenvirt.c
index 5a897b9..c08a056 100644
--- a/drivers/net/xenvirt/rte_eth_xenvirt.c
+++ b/drivers/net/xenvirt/rte_eth_xenvirt.c
@@ -765,5 +765,6 @@ static struct rte_vdev_driver pmd_xenvirt_drv = {
};
RTE_PMD_REGISTER_VDEV(net_xenvirt, pmd_xenvirt_drv);
+RTE_PMD_REGISTER_ALIAS(net_xenvirt, eth_xenvirt);
RTE_PMD_REGISTER_PARAM_STRING(net_xenvirt,
"mac=");
--
2.6.6
[dpdk-dev] [PATCH 1/3] mbuf: embedding timestamp into the packet
On Thu, Oct 20, 2016 at 4:03 AM, Oleg Kuporosov wrote: > Hello Konstantin, > >> >> My vote also would be to have timestamp in the second cache line. >> About moving seqn to the 2-nd cache line too - that's probably a fair point. > > It may impact throughput till ~6% for applications required such embedded > Timestamps. > >> About the rest of the patch: >> Do you really need to put that code into the PMDs itself? >> Can't the same result be achieved by using RX callbacks? >> Again that approach would work with any PMD and there would be no need >> to modify PMD code itself. > > Correct, the approach with using callbacs > (rte_eth_timesync_read_[r|t]x_timestamp()) > Has also some Cons for this use case: > - FSI needs the most accurate stamping as possible by reasons were described > in > Cover letter >From my experience this is only true if there is near-zero performance impact. From my perspective this is only relevant if the used hardware supports offloading of writing the timestamps. Everything else is a huge impact if its unconditionally enabled. The regulatory requirements are already covered by the exchange protocols which means that timestamps are already present in the network packet payload (generated by the exchange trading system and/or the trading application itself). In the end it is the exchange itself and its members that are regulated. I can see that this might be interesting for exchange members allowing sponsored naked access (for non-exchange members) to generate data that they are not front-running their clients. I doubt that this non-functional requirement is important enough to sacrifice the functional requirement of supporting QinQ. > - callback will be called from user app and so you have to take into account > Difference between time when packet was released by NIC and callback call Have you looked at using dedicated preallocated trace buffers that are filled with timestamps values? This should work fine for getting some inside into the latency between application readiness and the actual time the burst happened. Thanks, Jan > - such difference is not easy to estimate correctly due to dependency on CPU > type, > Its frequency and current load conditions > - even estimated it would be hard without additional performance penalty to > align > Packet with timestamp, taking account that call may actually placed from > Different thread or even process. > > It looks the least impacting and correct way is to have timestamp in rte_mbuf > and fill > It in Rx burst procedure. > >> Another thing, that I am in doubt why to use system time? >> Wouldn't raw HW TSC value (rte_rdtsc()) do here? > > System time is being used for periodic clock synchronization between wall > clock and NIC to estimate NIC clock deviation. It is in assumption the system > itself is > synchronized by PTP from master clock. It is run on context of control thread. > > Thanks, > Oleg.
[dpdk-dev] DPDK Summit Userspace - streaming live
If you couldn't make it to the Userspace event we are streaming it live on Periscope. https://www.periscope.tv/jimstleger The video quality isn't the best, but maybe some talks are worth listening to. The audio quality seems okay. The agenda and most of the presentations are posted online. https://dpdksummit.com/us/en/events Once the event is finished high quality video recordings will also get posted. Enjoy. Jim
[dpdk-dev] DPDK Summit Userspace - streaming live
On Thu, 2016-10-20 at 11:04 +, St Leger, Jim wrote: > If you couldn't make it to the Userspace event we are streaming it > live on Periscope.? https://www.periscope.tv/jimstleger > Thank you. This is much appreciated. Regards, Frederico
[dpdk-dev] [PATCH v2] lib/ether: prevent duplicate callback on list
This change prevents the attempt to add a structure which is
already on the callback list. If a struct with matching
parameters is found on the list, then no action is taken. If
a struct with matching parameters is found on the list, then
no action is taken.
Fixes: ac2f69c ("ethdev: fix crash if malloc of user callback fails")
Signed-off-by: E. Scott Daniels
---
V2:
* Correct the component name; changed from net/ixgbe.
* Add Fixes tag.
* Acked-by: Wenzhuo Lu
lib/librte_ether/rte_ethdev.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 0d9d9c1..fde8112 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -2449,14 +2449,15 @@ rte_eth_dev_callback_register(uint8_t port_id,
}
/* create a new callback. */
- if (user_cb == NULL)
+ if (user_cb == NULL) {
user_cb = rte_zmalloc("INTR_USER_CALLBACK",
sizeof(struct rte_eth_dev_callback), 0);
- if (user_cb != NULL) {
- user_cb->cb_fn = cb_fn;
- user_cb->cb_arg = cb_arg;
- user_cb->event = event;
- TAILQ_INSERT_TAIL(&(dev->link_intr_cbs), user_cb, next);
+ if (user_cb != NULL) {
+ user_cb->cb_fn = cb_fn;
+ user_cb->cb_arg = cb_arg;
+ user_cb->event = event;
+ TAILQ_INSERT_TAIL(&(dev->link_intr_cbs), user_cb, next);
+ }
}
rte_spinlock_unlock(&rte_eth_dev_cb_lock);
--
1.9.1
[dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on list
On Wed, 19 Oct 2016, DANIELS, EDWARD S (EDWARD) wrote: > *** Security Advisory: This Message Originated Outside of AT&T ***. > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > > > On Wed, 19 Oct 2016, Lu, Wenzhuo wrote: > >> Hi Scott, >> >>> -Original Message- >>> From: Scott Daniels [mailto:daniels at research.att.com] >>> Sent: Thursday, October 20, 2016 10:11 AM >>> To: Lu, Wenzhuo >>> Cc: Zhang, Helin; Iremonger, Bernard; dev at dpdk.org; ZELEZNIAK, ALEX >>> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on >>> list >>> >>> >>> >>> On Wed, 19 Oct 2016, Lu, Wenzhuo wrote: >>> Hi Scott, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of E. Scott Daniels > Sent: Thursday, October 20, 2016 6:23 AM > To: Zhang, Helin; Iremonger, Bernard > Cc: dev at dpdk.org; az5157 at att.com; E. Scott Daniels > Subject: [dpdk-dev] [PATCH] net/ixgbe: prevent duplicate callback on > list > > This change prevents the attempt to add a structure which is already > on the callback list. If a struct with matching parameters is found > on the list, then no action is taken. If a struct with matching > parameters is found on the list, then no action is taken. > > Signed-off-by: E. Scott Daniels I think the fix itself is good. But 2 things, 1, normally we don't create a cover letter for a patch set which only has one patch. Just sending the >>> patch itself is enough. 2, ' net/ixgbe: ' in the title is used to describe the component. So the title >>> should be ' lib/ether: prevent duplicate callback on list'. Thanks. >>> >>> Thanks for the advice. My mistake on the component. Is there an easy way >>> to >>> fix, or does it make sense just to nack this and I'll submit one with the >>> correct >>> component. >> No need to NACK it. You can send a V2 with the correct component. And I >> think you can add my ack in the V2. >> Acked-by: Wenzhuo Lu >> >> BTW, I forgot to mention that as it's a fix. We always add a Fixes tag in >> the commit log. You can find the example from other one's mails :) > > Will do. The patch checker was squaking about the fixes tag and I remvoed > it :( So, I need to figure out what it didn't like about it and I'll fix > with a V2 and add your ack. Getting late here tonight, so tomorrow. > > Thanks > Scott V2 created, but with the change to the component the subject is different: [PATCH v2] lib/ether: prevent duplicate callback on list > > >> > >>> >>> Scott >>> >> >
[dpdk-dev] [opnfv-tech-discuss][apex][ovsnfv]Problem showed up with OVS/DPDK with Cisco VIC adapter
Hi, Please see inline. Thanks, john > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas F Herbert > Sent: Tuesday, October 18, 2016 1:35 PM > To: dev at dpdk.org > Cc: Keith Burns ; Edward Warnicke > ; opnfv-tech-discuss at lists.opnfv.org > Subject: [dpdk-dev] [opnfv-tech-discuss][apex][ovsnfv]Problem showed up > with OVS/DPDK with Cisco VIC adapter > > All: > > This is not necessarily related to VPP but rather to OVS/DPDK. > In OPNFV we found the following problem when using UCS NIC. > The UCS fabric seems to set a VLAN tag on untagged packets. > Any thoughts from DPDK and VPP folks would be appreciated. > In a UCS fabric, all frames between the VIC and the Fabric Interconnect will be tagged. This is required to carry both VLAN information and, being a converged adapter supporting both Ethernet and FCoE, traffic class. For non-UCS fabric deployments, there is currently no way to turn off egress priority tagging on the VIC adapter. If a packet being sent from DPDK to the enic PMD is priority tagged (VLAN=0) or has no VLAN tag, the default VLAN tag (as set up in CIMC/UCSM manager) will be inserted. This should only be an issue with C-series UCS servers connected point to point or through a switch that can't cope with priority tags. Is that the case here? > ... > -- > *Thomas F Herbert* > SDN Group > Office of Technology > *Red Hat*
[dpdk-dev] [PATCH] openssl pmd: rename SW crypto device from libcrypto to openssl
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jain, Deepak K
> Sent: Wednesday, October 19, 2016 1:27 AM
> To: Mrozowicz, SlawomirX; Doherty, Declan
> Cc: dev at dpdk.org; Mrozowicz, SlawomirX
> Subject: Re: [dpdk-dev] [PATCH] openssl pmd: rename SW crypto device from
> libcrypto to openssl
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Slawomir
> > Mrozowicz
> > Sent: Tuesday, October 18, 2016 12:36 PM
> > To: Doherty, Declan
> > Cc: dev at dpdk.org; Mrozowicz, SlawomirX
> >
> > Subject: [dpdk-dev] [PATCH] openssl pmd: rename SW crypto device from
> > libcrypto to openssl
> >
> > This patch replaces name "libcrypto" to "openssl" from file directories,
> > symbol prefixes and sub-names connected with old name.
> > Renamed poll mode driver files, test files, and documentations.
> > It is done to better name association with library because
> > the cryptography operations are using Openssl library crypto API.
> >
> > Fixes: d61f70b4c918 ("crypto/libcrypto: add driver for OpenSSL library")
> >
> > Signed-off-by: Slawomir Mrozowicz
> > ---
> > MAINTAINERS|6 +-
> > app/test/test_cryptodev.c | 56 +-
> > app/test/test_cryptodev_aes_test_vectors.h | 62 +-
> > app/test/test_cryptodev_blockcipher.c |6 +-
> > app/test/test_cryptodev_blockcipher.h |2 +-
> > app/test/test_cryptodev_des_test_vectors.h | 56 +-
> > app/test/test_cryptodev_hash_test_vectors.h| 48 +-
> > app/test/test_cryptodev_perf.c | 52 +-
> > config/common_base |4 +-
> > delete mode 100644
> > drivers/crypto/libcrypto/rte_pmd_libcrypto_version.map
> > create mode 100644 drivers/crypto/openssl/Makefile
> > create mode 100644 drivers/crypto/openssl/rte_openssl_pmd.c
> > create mode 100644 drivers/crypto/openssl/rte_openssl_pmd_ops.c
> > create mode 100644 drivers/crypto/openssl/rte_openssl_pmd_private.h
> > create mode 100644
> drivers/crypto/openssl/rte_pmd_openssl_version.map
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8f5fa82..af47e04 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > --
> > 2.5.0
> Acked-by: Deepak Kumar Jain
Applied to dpdk-next-crypto.
Thanks,
Pablo
