[dpdk-dev] [RFC PATCH] Enable uio_pci_generic support
Linux kernel provides UIO as well as VFIO mechanism to support writing user
space device driver. Comparing to UIO which is available since 2.6.32 kernel,
the VFIO is introduced into kernel since version 3.6.0 with better interrupt
and memory protection (build on top of Intel VT-d technology) supports.
Basically, UIO and VFIO do two common things below:
1) Map PCIe device's I/O memory space to user space driver
2) Support device interrupt notification mechanism allows user space
driver/application is notified when device interrupt triggers.
To run an DPDK application and make use of VFIO, two in_kernel modules
vfio and vfio-pci module must be loaded. But to use UIO, a DPDK kernel
module igb_uio, which was there since DPDK is invented, must be loaded to
attach to in_kernel uio module. As an possible solution to deprecate igb_uio,
this RFC patch leverages uio_pci_generic this in_kernel module to support
DPDK user space PMD in a generic fashion (like how VFIO works today), to
partially (DPDK KNI module rte_kni still sits in kernel) remove DPDK dependency
on GPL code igb_uio in kernel. Tests with uio_pci_generic shows performance
remains same and LSC interrupts works as before.
Example to bind Network Ports to uio_pci_generic:
modprobe uio
modprobe uio_pci_generic
/* to bind device 08:00.0, to the uio_pci_generic driver */
./tools/dpdk_nic_bind.py -b uio_pci_generic 08:00.0
Note: this RFC patch does not completely remove igb_uio support due to
igb_uio supports creating maximum number of SR-IOV VFs (Virtual Functions)
by using max_vfs kernel parameter on older kernels (kernel 3.7.x and below).
Specifically, igb_uio explicitly calls pci_enable_sriov() to create VFs, while
it is not invoked in either uio or uio_pci_generic. On kernel 3.8.x
and above, user can use the standard sysfs to enable VFs. For examples:
#echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs //enable VFs
#echo 0 > /sys/class/net/$dev/device/sriov_numvfs //disable VFs
---
lib/librte_eal/common/include/rte_pci.h| 1 +
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 67 +--
lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +-
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 203 -
.../linuxapp/eal/include/exec-env/rte_interrupts.h | 1 +
tools/dpdk_nic_bind.py | 2 +-
6 files changed, 214 insertions(+), 62 deletions(-)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 66ed793..71ca882 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -148,6 +148,7 @@ struct rte_pci_device {
struct rte_pci_id id; /**< PCI ID. */
struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE]; /**< PCI
Memory Resource */
struct rte_intr_handle intr_handle; /**< Interrupt handle */
+ char driver_name[BUFSIZ]; /**< driver name */
const struct rte_pci_driver *driver;/**< Associated driver */
uint16_t max_vfs; /**< sriov enable if not zero */
int numa_node; /**< NUMA node connection */
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index dc2668a..f2da778 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -361,6 +361,53 @@ vfio_disable_msix(struct rte_intr_handle *intr_handle) {
}
#endif
+static int
+uio_intr_enable(struct rte_intr_handle *intr_handle)
+{
+ unsigned char command_high;
+
+ /* use config file descriptor for uio_pci_generic */
+ if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ RTE_LOG(ERR, EAL,
+ "Error reading interrupts status for fd %d\n",
+ intr_handle->uio_cfg_fd);
+ return -1;
+ }
+ /* disable interrupts */
+ command_high |= 0x4;
+ if (pwrite(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ RTE_LOG(ERR, EAL,
+ "Error disabling interrupts for fd %d\n",
+ intr_handle->uio_cfg_fd);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int
+uio_intr_disable(struct rte_intr_handle *intr_handle)
+{
+ unsigned char command_high;
+
+ if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ RTE_LOG(ERR, EAL,
+ "Error reading interrupts status for fd %d\n",
+ intr_handle->uio_cfg_fd);
+ return -1;
+ }
+ /* enable interrupts */
+ command_high &= ~0x4;
+ if (pwrite(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ RTE_LOG(ERR, EAL,
+ "Error enabling interrupts for fd %d\n",
+
[dpdk-dev] Tx doesn't work on PCI-passthrough I350
Hi, My setup: Qemu+KVM Host OS: CentOS, Linux kernel version 2.6.32 Guest OS: Linux kernel version 3.10.0, with a DPDK application running. Physical NIC: Intel I350 T4 using igb driver On guest VM: 2 (out of 4) ports of the I350 are virtualized using PCI-passthrough (no VFs, SR-IOV is not enabled in the NIC eeprom) 2 other (non-DPDK) VMs are connected through the DPDK VM as follows: VM1---DPDK VM---VM2 On doing a ping from VM1 to VM2 (or the other way), on the DPDK VM, the packet is received on 1 port and sent out of the other but doesn't reach VM2. I turned on CONFIG_RTE_LIBRTE_E1000_DEBUG_RX and CONFIG_RTE_LIBRTE_E1000_DEBUG_TX but couldn't figure out where the transmitted packet went. How can I debug this issue? For comparison, the same setup works if the guest VM uses emulated e1000 NICs. I want to use igb/PCI-passthrough to be able to use multiple RX queues. Please let me know if any other information is required. Thanks, Anant
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
Hi Thomas Sorry, I should have answer your comments together with my reworking the latest patch set. Please see my answers for your comments! I really appreciate your comments! > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Wednesday, October 22, 2014 4:54 AM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of > redirection table > > 2014-09-25 16:40, Helin Zhang: > > To support possible different sizes of redirection table, structures > > and functions need to be redefined. In detail, > > * 'struct rte_eth_rss_reta' has been redefined. > > * 'uint16_t reta_size' has been added into > > 'struct rte_eth_dev_info'. > > * Updating/querying reta have been reimplemented with one > > more parameter of redirection table size. > > > > v2 changes: > > * Put changes for supporting multiple sizes of reta in > > ethdev into a single patch. > > In order to allow usage of git bisect, compilation must not be broken, even > inside > a patchset. > So when refactoring an existing API, you must adapt the dependent code in the > same patch. > To make things easy to review, please try to change API incrementally with > good > explanation of why each change is needed. OK. The patch set has been reworked to get all patches compiled well. > > > /* Definitions used for redirection table entry size */ -#define > > ETH_RSS_RETA_NUM_ENTRIES 128 > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > +#define ETH_RSS_RETA_SIZE_64 64 > > +#define ETH_RSS_RETA_SIZE_128 128 > > +#define ETH_RSS_RETA_SIZE_512 512 > > + > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > Are these constants really needed? These constants were defined for the third input parameter of rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End users need to give the correct reta size listed as above, as other values is not valid. So it would be better to list the valid reta sizes in macros here. > > > /** > > - * A structure used to configure Redirection Table of the Receive > > Side > > - * Scaling (RSS) feature of an Ethernet port. > > + * A structure used to configure 64 entries of Redirection Table of > > + the > > + * Receive Side Scaling (RSS) feature of an Ethernet port. To > > + configure > > + * more than 64 entries supported by hardware, an array of this > > + structure > > + * is needed. > > */ > > Explaining the array of 64 entries could be useful in commit log. > Please don't forget to answer the "why" question in commit logs. OK. Rework for this has been done in the latest version of patch set. > > Thanks > -- > Thomas Thanks, Helin
[dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of redirection table
Hi Thomas See my answers inlined. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Monday, October 27, 2014 10:24 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of > redirection table > > 2014-10-22 19:53, Helin Zhang: > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > How can it be different of 64? > Using 64 would be simpler to understand than RTE_BIT_WIDTH_64. > > > + uint8_t reta[RTE_BIT_WIDTH_64]; /**< 64 redirection table entries. */ We always try to use macro in code to replace numeric, this can get the numeric more understandable. > > Even your comment is saying that it's 64. > > -- > Thomas Regards, Helin
[dpdk-dev] [PATCH v4 00/21] Support flow director programming on Fortville
Acked-by: Helin Zhang I have reviewed the differences between v3 and v4. It seems OK for me. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jingjing Wu > Sent: Wednesday, October 22, 2014 9:01 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v4 00/21] Support flow director programming on > Fortville > > The patch set supports flow director on fortville. > It includes: > - set up/tear down fortville resources to support flow director, such as > queue > and vsi. > - support operation to add or delete 8 flow types of the flow director > filters, > they are ipv4, tcpv4, udpv4, sctpv4, ipv6, tcpv6, udpv6, sctpv6. > - support flushing flow director table (all filters). > - support operation to get flow director information. > - match status statistics, FD_ID report. > - support operation to configure flexible payload and its mask > - support flexible payload involved in comparison and flex bytes report. > > v2 changes: > - create real fdir vsi and assign queue 0 pair to it. > - check filter status report on the rx queue 0 > > v3 changes: > - redefine filter APIs to support multi-kind filters > - support sctpv4 and sctpv6 type flows > - support flexible payload involved in comparison > > v4 changes: > - strip the filter APIs definitions from this patch set > - extend mbuf field to support flex bytes report > - fix typos > > Jingjing Wu (21): > i40e: set up and initialize flow director > i40e: tear down flow director > i40e: initialize flexible payload setting > ethdev: define structures for adding/deleting flow director > i40e: implement operations to add/delete flow director > testpmd: add test commands to add/delete flow director filter > i40e: match counter for flow director > mbuf: extend fdir field > i40e: report flow director match info to mbuf > testpmd: print extended fdir info in mbuf > ethdev: define structures for getting flow director information > i40e: implement operations to get fdir info > testpmd: display fdir statistics > i40e: implement operation to flush flow director table > testpmd: add test command to flush flow director table > ethdev: define structures for configuring flexible payload > i40e: implement operations to configure flexible payload > testpmd: add test command to configure flexible payload > ethdev: define structures for configuring flex masks > i40e: implement operations to configure flexible masks > testpmd: add test command to configure flexible masks > > app/test-pmd/cmdline.c| 812 > app/test-pmd/config.c | 38 +- > app/test-pmd/rxonly.c | 14 +- > app/test-pmd/testpmd.h|3 + > lib/librte_ether/rte_eth_ctrl.h | 266 > lib/librte_ether/rte_ethdev.h | 23 - > lib/librte_mbuf/rte_mbuf.h| 12 +- > lib/librte_pmd_i40e/Makefile |2 + > lib/librte_pmd_i40e/i40e_ethdev.c | 127 +++- > lib/librte_pmd_i40e/i40e_ethdev.h | 34 +- > lib/librte_pmd_i40e/i40e_fdir.c | 1222 > + > lib/librte_pmd_i40e/i40e_rxtx.c | 225 ++- > 12 files changed, 2723 insertions(+), 55 deletions(-) create mode 100644 > lib/librte_pmd_i40e/i40e_fdir.c > > -- > 1.8.1.4
[dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director
Hi, Thomas
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, October 28, 2014 12:58 AM
> To: Wu, Jingjing
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 04/21] ethdev: define structures for
> adding/deleting flow director
>
> 2014-10-22 09:01, Jingjing Wu:
> > +/**
> > + * A structure used to define the input for IPV4 UDP flow */ struct
> > +rte_eth_udpv4_flow {
> > + uint32_t src_ip; /**< IPv4 source address to match. */
> > + uint32_t dst_ip; /**< IPv4 destination address to match. */
> > + uint16_t src_port;/**< UDP Source port to match. */
> > + uint16_t dst_port;/**< UDP Destination port to match. */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 TCP flow */ struct
> > +rte_eth_tcpv4_flow {
> > + uint32_t src_ip; /**< IPv4 source address to match. */
> > + uint32_t dst_ip; /**< IPv4 destination address to match. */
> > + uint16_t src_port;/**< TCP Source port to match. */
> > + uint16_t dst_port;/**< TCP Destination port to match. */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 SCTP flow */ struct
> > +rte_eth_sctpv4_flow {
> > + uint32_t src_ip; /**< IPv4 source address to match. */
> > + uint32_t dst_ip; /**< IPv4 destination address to match. */
> > + uint32_t verify_tag; /**< verify tag to match */
> > +};
> > +
> > +/**
> > + * A structure used to define the input for IPV4 flow */ struct
> > +rte_eth_ipv4_flow {
> > + uint32_t src_ip; /**< IPv4 source address to match. */
> > + uint32_t dst_ip; /**< IPv4 destination address to match. */
> > +};
>
> Why not defining only 1 structure?
> struct rte_eth_ipv4_flow {
> uint32_t src_ip;
> uint32_t dst_ip;
> uint16_t src_port;
> uint16_t dst_port;
> uint32_t sctp_tag;
> };
>
> I think the same structure could be used for many filters (not only flow
> director).
>
Yes, one structure can contain all the elements we need, but I think it will be
clearer that each kind of flow type has its key words.
> > +#define RTE_ETH_FDIR_MAX_FLEXWORD_LEN 8
> > +/**
> > + * A structure used to contain extend input of flow */ struct
> > +rte_eth_fdir_flow_ext {
> > + uint16_t vlan_tci;
> > + uint8_t num_flexwords; /**< number of flexwords */
> > + uint16_t flexwords[RTE_ETH_FDIR_MAX_FLEXWORD_LEN];
> > + uint16_t dest_id; /**< destination vsi or pool id*/
> > +};
>
> Flexword should be explained.
>
The flexword means the application can choose a part of packet's payload as key
words to compare match. It is flexible. In Ixgbe, the flexwords is 1 word (2
bytes), while Fortville extend it to 8 words.
> > +/**
> > + * A structure used to define the input for an flow director filter
> > +entry
>
> typo: for *a* flow director
Yes, will change.
>
> > + */
> > +struct rte_eth_fdir_input {
> > + enum rte_eth_flow_type flow_type; /**< type of flow */
> > + union rte_eth_fdir_flow flow; /**< specific flow structure */
> > + struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info */ };
>
> I don't understand the logic behind flow/flow_ext.
> Why flow_ext is not merged into flow ?
>
The flow defines the key words for each flow_type, while the flow_ext has other
elements which have little to do with flow_type. For example the flexword,
dst_id (can used as pool id), I think it is not reasonable to make it as an
element in the flow.
> > +/**
> > + * Flow director report status
> > + */
> > +enum rte_eth_fdir_status {
> > + RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< no report FDIR. */
> > + RTE_ETH_FDIR_REPORT_FD_ID, /**< only report FD ID. */
> > + RTE_ETH_FDIR_REPORT_FD_ID_FLEX_4, /**< report FD ID and 4 flex
> bytes. */
> > + RTE_ETH_FDIR_REPORT_FLEX_8,/**< report 8 flex bytes. */
> > +};
>
> The names and explanations are cryptics.
The enum defines what will be reported when FIR match. Can be FD_ID or flex
bytes
> Is FD redundant with FDIR?
Yes, good point. Will remove FD.
>
> > +/**
> > + * A structure used to define an action when match FDIR packet filter.
> > + */
> > +struct rte_eth_fdir_action {
> > + uint16_t rx_queue;/**< queue assigned to if fdir match. */
> > + uint16_t cnt_idx; /**< statistic counter index */
>
> what is the action of "statistic counter index"?
When FD match happened, the counter will increase. Fortville can support to
configure the different counter for filter entries. The action is a part of a
filter entry, so this element means which counter the entry will use.
>
> > + uint8_t drop;/**< accept or reject */
> > + uint8_t flex_off;/**< offset used define words to report */
>
> still difficult to understand the flex logic
Just as mentioned above, Fortville can support 8 flex words comparing. But for
reporting, only 4 or 8 bytes in the flex words can be
[dpdk-dev] [RFC PATCH] Enable uio_pci_generic support
Tested-by: Michael Qiu
? 10/28/2014 1:49 AM, Danny Zhou ??:
> Linux kernel provides UIO as well as VFIO mechanism to support writing user
> space device driver. Comparing to UIO which is available since 2.6.32 kernel,
> the VFIO is introduced into kernel since version 3.6.0 with better interrupt
> and memory protection (build on top of Intel VT-d technology) supports.
> Basically, UIO and VFIO do two common things below:
> 1) Map PCIe device's I/O memory space to user space driver
> 2) Support device interrupt notification mechanism allows user space
>driver/application is notified when device interrupt triggers.
>
> To run an DPDK application and make use of VFIO, two in_kernel modules
> vfio and vfio-pci module must be loaded. But to use UIO, a DPDK kernel
> module igb_uio, which was there since DPDK is invented, must be loaded to
> attach to in_kernel uio module. As an possible solution to deprecate igb_uio,
> this RFC patch leverages uio_pci_generic this in_kernel module to support
> DPDK user space PMD in a generic fashion (like how VFIO works today), to
> partially (DPDK KNI module rte_kni still sits in kernel) remove DPDK
> dependency
> on GPL code igb_uio in kernel. Tests with uio_pci_generic shows performance
> remains same and LSC interrupts works as before.
>
> Example to bind Network Ports to uio_pci_generic:
> modprobe uio
> modprobe uio_pci_generic
> /* to bind device 08:00.0, to the uio_pci_generic driver */
> ./tools/dpdk_nic_bind.py -b uio_pci_generic 08:00.0
>
> Note: this RFC patch does not completely remove igb_uio support due to
> igb_uio supports creating maximum number of SR-IOV VFs (Virtual Functions)
> by using max_vfs kernel parameter on older kernels (kernel 3.7.x and below).
> Specifically, igb_uio explicitly calls pci_enable_sriov() to create VFs, while
> it is not invoked in either uio or uio_pci_generic. On kernel 3.8.x
> and above, user can use the standard sysfs to enable VFs. For examples:
>
> #echo $num_vf_enabled > /sys/class/net/$dev/device/sriov_numvfs //enable VFs
> #echo 0 > /sys/class/net/$dev/device/sriov_numvfs //disable
> VFs
>
> ---
> lib/librte_eal/common/include/rte_pci.h| 1 +
> lib/librte_eal/linuxapp/eal/eal_interrupts.c | 67 +--
> lib/librte_eal/linuxapp/eal/eal_pci.c | 2 +-
> lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 203
> -
> .../linuxapp/eal/include/exec-env/rte_interrupts.h | 1 +
> tools/dpdk_nic_bind.py | 2 +-
> 6 files changed, 214 insertions(+), 62 deletions(-)
>
> diff --git a/lib/librte_eal/common/include/rte_pci.h
> b/lib/librte_eal/common/include/rte_pci.h
> index 66ed793..71ca882 100644
> --- a/lib/librte_eal/common/include/rte_pci.h
> +++ b/lib/librte_eal/common/include/rte_pci.h
> @@ -148,6 +148,7 @@ struct rte_pci_device {
> struct rte_pci_id id; /**< PCI ID. */
> struct rte_pci_resource mem_resource[PCI_MAX_RESOURCE]; /**< PCI
> Memory Resource */
> struct rte_intr_handle intr_handle; /**< Interrupt handle */
> + char driver_name[BUFSIZ]; /**< driver name */
> const struct rte_pci_driver *driver;/**< Associated driver */
> uint16_t max_vfs; /**< sriov enable if not zero */
> int numa_node; /**< NUMA node connection */
> diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> index dc2668a..f2da778 100644
> --- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
> @@ -361,6 +361,53 @@ vfio_disable_msix(struct rte_intr_handle *intr_handle) {
> }
> #endif
>
> +static int
> +uio_intr_enable(struct rte_intr_handle *intr_handle)
> +{
> + unsigned char command_high;
> +
> + /* use config file descriptor for uio_pci_generic */
> + if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
> + RTE_LOG(ERR, EAL,
> + "Error reading interrupts status for fd %d\n",
> + intr_handle->uio_cfg_fd);
> + return -1;
> + }
> + /* disable interrupts */
> + command_high |= 0x4;
> + if (pwrite(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
> + RTE_LOG(ERR, EAL,
> + "Error disabling interrupts for fd %d\n",
> + intr_handle->uio_cfg_fd);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> +static int
> +uio_intr_disable(struct rte_intr_handle *intr_handle)
> +{
> + unsigned char command_high;
> +
> + if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
> + RTE_LOG(ERR, EAL,
> + "Error reading interrupts status for fd %d\n",
> + intr_handle->uio_cfg_fd);
> + return -1;
> + }
> + /* enable interrupts */
> + comman
[dpdk-dev] ethtool and igb/ixgbe (kni)
On Mon, Oct 27, 2014 at 07:49:03PM +0200, Kevin Wilson wrote: > Poke! > Can anybody advice about this question ? > Kevin > > On Fri, Oct 24, 2014 at 12:54 PM, Kevin Wilson wrote: > > Hi, > > > > I am looking in the file hierarchy of dpdk, and I see that under > > /dpdk-1.7.1/lib/librte_eal/linuxapp/kni/ethtool > > we have: > > igb ixgbe README > > > > My question is: why the igb and ixgbe are on this path, under ethtool > > ? are they related > > to ethtool in any way ? > > > > > > The README does not explain it. > > > > Regards, > > Kevin The code for igb and ixgbe are under that path to allow the kernel net devs created by the KNI to have ethtool support for manipulating the underlying NIC. /Bruce
[dpdk-dev] [PATCH v3 7/8] ethdev: support of multiple sizes of redirection table
2014-10-28 00:37, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-10-22 19:53, Helin Zhang: > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > How can it be different of 64? > > Using 64 would be simpler to understand than RTE_BIT_WIDTH_64. > > > > > + uint8_t reta[RTE_BIT_WIDTH_64]; /**< 64 redirection table entries. */ > We always try to use macro in code to replace numeric, this can get the > numeric more understandable. How bit width 64 is more understandable than 64? Especially when you count a number of entries, not a bit width. RETA_ENTRIES_MAX would be more understandable. -- Thomas
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
2014-10-28 00:33, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-09-25 16:40, Helin Zhang: > > > /* Definitions used for redirection table entry size */ > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > +#define ETH_RSS_RETA_SIZE_64 64 > > > +#define ETH_RSS_RETA_SIZE_128 128 > > > +#define ETH_RSS_RETA_SIZE_512 512 > > > + > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > Are these constants really needed? > > These constants were defined for the third input parameter of > rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End users need > to give the correct reta size listed as above, as other values is not valid. > So it would be > better to list the valid reta sizes in macros here. OK, so you should explain that only these values are allowed. In general, it's something we explain in the comment of the function. By the way, why only these values are allowed? -- Thomas
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > Sent: Tuesday, October 28, 2014 10:10 AM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of > redirection table > > 2014-10-28 00:33, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2014-09-25 16:40, Helin Zhang: > > > > /* Definitions used for redirection table entry size */ > > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > +#define ETH_RSS_RETA_SIZE_64 64 > > > > +#define ETH_RSS_RETA_SIZE_128 128 > > > > +#define ETH_RSS_RETA_SIZE_512 512 > > > > + > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > Are these constants really needed? > > > > These constants were defined for the third input parameter of > > rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End users > need > > to give the correct reta size listed as above, as other values is not > > valid. So it > would be > > better to list the valid reta sizes in macros here. > If only limited range of values are allowed, would an enum work better than a set of macros? > OK, so you should explain that only these values are allowed. > In general, it's something we explain in the comment of the function. > > By the way, why only these values are allowed?
[dpdk-dev] [PATCH] mk: link combined lib using CC
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez > Monroy > Sent: Thursday, October 23, 2014 4:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] mk: link combined lib using CC > > Building combined shared libs fails if we set EXTRA_CFLAGS=-O0. > > /usr/bin/ld: test: hidden symbol `mknod' in > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > Signed-off-by: Sergio Gonzalez Monroy > > --- > mk/rte.lib.mk | 1 - > mk/rte.sharelib.mk | 12 +++- > 2 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk > index d83e808..a6abd6d 100644 > --- a/mk/rte.lib.mk > +++ b/mk/rte.lib.mk > @@ -63,7 +63,6 @@ ifeq ($(LINK_USING_CC),1) > # Override the definition of LD here, since we're linking with CC > LD := $(CC) $(CPU_CFLAGS) > LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs) > -CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS)) > endif Patch does not apply cleanly, due to context mismatch. Could you send a V2, based on the current branch status? Plus, should we include compilation errors in commits? They are quite useful to identify the problem that the patch is solving, but not sure if this should be shown in the git log. Thanks, Pablo
[dpdk-dev] rte_acl test-acl app
Hi Erik, > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Erik Ziegenbalg > Sent: Saturday, October 25, 2014 4:19 AM > To: dev at dpdk.org > Subject: [dpdk-dev] rte_acl test-acl app > > Hi everyone, > > I am having trouble to successfully perform a packet classification > using the rte_acl test app. I have my rules.acl and trace.acl files as > follows: > > rules.acl: > @192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff > > trace.acl: > 192.168.0.5 192.168.0.9 450 1002 0x06 > > However, the result always comes up as 4294967295 (x). I have > dug through the code quite a bit to follow and see what is going on, but > not sure where I went wrong. > > Any help on how the rte_acl_classify function works would be much > appreciated. In understand that the data for rte_acl_classify is a > uint32_t ** and I double checked to make sure I'm passing along proper > values. Is x the expected result? If so, I am getting the same > for packets that should not match. That's strange: for me latest code with dpdk.org works as expected: # cat ./test/rule1 @192.168.0.0/24 192.168.0.0/24 400 : 500 1000 : 2000 6/0xff # cat ./test/trace1 0xc0a80005 0xc0a80009 450 1002 0x06 # ./dpdk.org/x86_64-native-linuxapp-gcc/app/testacl -n 2 -c 4 -- --rulesf=./test/rule1--tracef=./test/trace1 ipv4_5tuple: 1, category: 0, result: 0 ... i.e: rule #0 matches given flow, as expected. Do you use testacl or some other app? Konstantin > > Thank you, > Erik Ziegenbalg
[dpdk-dev] [PATCH v2] librte_ip_frag: Disable ipv4/v6 fragmentation if RTE_MBUF_REFCNT=n
On Wed, Oct 22, 2014 at 12:17:01PM +0100, Pablo de Lara wrote: > rte_ipv4_fragment_packet() and rte_ipv6_fragment packet() > call rte_pktmbuf_attach() to attach the segment of the original > packet to the segment of the new fragmented one. Such function > is not declared if RTE_MBUF_REFCNT is disabled, as it needs to > call rte_mbuf_refcnt_update, not declared either. > > Therefore, the ipv4/v6 fragmentation libraries are disabled > in that situation. > > Signed-off-by: Pablo de Lara > --- > lib/librte_ip_frag/Makefile |6 +- > lib/librte_ip_frag/rte_ip_frag.h |5 - > 2 files changed, 9 insertions(+), 2 deletions(-) > Acked-by: Sergio Gonzalez Monroy
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
Hi Thomas > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, October 28, 2014 6:10 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of > redirection table > > 2014-10-28 00:33, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2014-09-25 16:40, Helin Zhang: > > > > /* Definitions used for redirection table entry size */ -#define > > > > ETH_RSS_RETA_NUM_ENTRIES 128 > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > +#define ETH_RSS_RETA_SIZE_64 64 > > > > +#define ETH_RSS_RETA_SIZE_128 128 #define ETH_RSS_RETA_SIZE_512 > > > > +512 > > > > + > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > Are these constants really needed? > > > > These constants were defined for the third input parameter of > > rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End > > users need to give the correct reta size listed as above, as other > > values is not valid. So it would be better to list the valid reta sizes in > > macros > here. > > OK, so you should explain that only these values are allowed. > In general, it's something we explain in the comment of the function It would be better to add comments for the functions. > > By the way, why only these values are allowed? It depends on hardware, 1G/10G hardware supports 128 reta size only, 40G hardware supports 512 or 128 depends on hardware configuration, 40G VF hardware supports 64. If more is introduced in the future, more values can be added later. It will return with errors if reta size is not supported for specific hardware. > > -- > Thomas Regards, Helin
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
2014-10-28 12:00, Zhang, Helin: > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > 2014-10-28 00:33, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > 2014-09-25 16:40, Helin Zhang: > > > > > /* Definitions used for redirection table entry size */ > > > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > > +#define ETH_RSS_RETA_SIZE_64 64 > > > > > +#define ETH_RSS_RETA_SIZE_128 128 > > > > > +#define ETH_RSS_RETA_SIZE_512 512 [...] > > By the way, why only these values are allowed? > > It depends on hardware, 1G/10G hardware supports 128 reta size only, 40G > hardware supports 512 or 128 depends on hardware configuration, 40G VF > hardware supports 64. If more is introduced in the future, more values can be > added later. It will return with errors if reta size is not supported for > specific hardware. So maybe it should be the responsibility of the driver to use the right value. This kind of hardware differences should be abstracted for the application. If the application need to know the size, a "get" function could be provided. -- Thomas
[dpdk-dev] Cannot mmap device resource in DPDK 1.7.0 multi-process/multi-thread
> -Original Message- > From: Mario Gianni [mailto:m.gianni at engineer.com] > Sent: Friday, October 24, 2014 4:03 PM > To: Richardson, Bruce > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Cannot mmap device resource in DPDK 1.7.0 multi- > process/multi-thread > > So you are telling me that in order to implement multi-process I should better > use the l2fwd_fork example instead of client_server_mp. > In fact if I use the client_server_mp with a lot of mp_client threads it > gives me > the error. > If instead I use the l2fwd_fork example it doesn't give me the error. > > One more question at this point: > Assume that I use l2fwd_fork, when I launch the secondary process, how do I > assign the lcore coremask associated with that process? > With the l2fwd_fork example, the forked processes are not secondary proceses in the sense of the other DPDK multiprocess models - with each one having its own core mask and set of threads. Instead, each forked process is a single thread based off the core-mask provided at process startup. It's a different way of doing things, but one which provides separate processes, while guaranteeing that all processes can share the same hugepage memory at the same address without relying on having the kernel map things at specific points in the address space. /Bruce
[dpdk-dev] [PATCH v2 0/4] app/test: unit test to measure cycles per packet
On Fri, Oct 10, 2014 at 08:29:57PM +0800, Cunming Liang wrote: > v2 update: > Rebase code to the latest master branch. > > -- > > Tested-by: Zhaochen Zhan > This patch has been verified on ixgbe and it is ready to be integrated to > dpdk.org. > For e1000 and i40e, lacking loopback supporting, this patch can't support > them for now. > > It provides unit test to measure cycles/packet in NIC loopback mode. > It simply gives the average cycles of IO used per packet without test > equipment. > When doing the test, make sure the link is UP. > > There's two stream control mode support, one is continues, another is burst. > The former continues to forward the injected packets until reaching a certain > amount of number. > The latter one stop when all the injected packets are received. > In burst stream, now measure two situations, with or without desc. cache > conflict. > By default, it runs in continues stream mode to measure the whole rxtx. > > Usage Example: > 1. Run unit test app in interactive mode > app/test -c f -n 4 -- -i > 2. Set stream control mode, by default is continuous > set_rxtx_sc [continuous|poll_before_xmit|poll_after_xmit] > 3. If choose continuous stream, there are another two options can configure > 3.1 choose rx/tx pair, default is vector > set_rxtx_mode [vector|scalar|full|hybrid] > Note: To get acurate scalar fast, plz choose 'vector' or 'hybrid' > without INC_VEC=y in config > 3.2 choose the area of masurement, default is rxtx > set_rxtx_anchor [rxtx|rxonly|txonly] > 4. Run and wait for the result > pmd_perf_autotest > > For who simply just want to see how much cycles cost per packet. > Compile DPDK, Run 'app/test', and type 'pmd_perf_autotest', that's it. > Nothing else needs to configure. > Using other options when you understand and what to measures more. > > *** BLURB HERE *** > > Cunming Liang (4): > app/test: unit test for rx and tx cycles/packet > app/test: measure standalone rx or tx cycles/packet > app/test: add unit test to measure RX burst cycles > app/test: allow to create packets in different sizes > > app/test/Makefile |1 + > app/test/commands.c | 111 + > app/test/packet_burst_generator.c | 26 +- > app/test/packet_burst_generator.h | 11 +- > app/test/test.h |6 + > app/test/test_link_bonding.c| 39 +- > app/test/test_pmd_perf.c| 922 > +++ > lib/librte_pmd_ixgbe/ixgbe_ethdev.c |6 + > 8 files changed, 1089 insertions(+), 33 deletions(-) > create mode 100644 app/test/test_pmd_perf.c > > -- > 1.7.4.1 > > Given that a subsequent patch was submitted to bring the debug and non-debug versions of rte_eth_rx_burst behavior in line Acked-by: Neil Horman
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
Hi Thomas > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, October 28, 2014 8:13 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of > redirection table > > 2014-10-28 12:00, Zhang, Helin: > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > 2014-10-28 00:33, Zhang, Helin: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > 2014-09-25 16:40, Helin Zhang: > > > > > > /* Definitions used for redirection table entry size */ > > > > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > > > +#define ETH_RSS_RETA_SIZE_64 64 #define > > > > > > +ETH_RSS_RETA_SIZE_128 128 #define ETH_RSS_RETA_SIZE_512 512 > [...] > > > By the way, why only these values are allowed? > > > > It depends on hardware, 1G/10G hardware supports 128 reta size only, > > 40G hardware supports 512 or 128 depends on hardware configuration, > > 40G VF hardware supports 64. If more is introduced in the future, more > > values can be added later. It will return with errors if reta size is not > > supported > for specific hardware. > > So maybe it should be the responsibility of the driver to use the right > value. This > kind of hardware differences should be abstracted for the application. > If the application need to know the size, a "get" function could be provided. Yes, the size can be gotten by ops of 'dev_infos_get'. But if end users know the size of a specific port, he can just use these macros directly without getting it from somewhere. > > -- > Thomas Regards, Helin
[dpdk-dev] [PATCH v3 00/10] split architecture specific operations
The set of patches split x86 architecture specific operations from DPDK and put them to x86 arch directory. This will make the adoption of DPDK much easier on other computer architecture. For a new architecture, just add an architecture specific directory and necessary building configuration files, then DPDK eal library can support it. Reviewing patchset from Chao, I ended up modifying it along the way, so here is a new iteration of this patchset. Changes since Chao v2 patchset : - added a preliminary patch for moving rte_atomic.h (for better readability) - fixed documentation generation - implemented a generic header for each arch specific header (cpuflags, memcpy, prefetch were missing) - removed C++ stuff from generic headers - centralised all doxygen stuff in generic headers (no need to have duplicates) - refactored rte_cycles functions - moved vmware tsc stuff to arch rte_cycles.h headers - finished x86 factorisation Little summary of current state : - all applications continue to include the eal headers as before, these headers are the arch-specific ones - the arch specific headers always include the generic ones. The generic headers contain the doxygen documentation and code common to all architectures - a x86 architecture has been defined which handles both 32bits and 64bits peculiarities It builds fine for 32/64 bits (w and w/o "force intrinsics"), but I really would like a lot of eyes on this (and I would say, especially, rte_cycles, rte_memcpy and rte_cpuflags). I still have some concerns about the use of intrinsics for architecture != x86 but I think Chao will be the best to look at this. -- David Marchand Chao Zhu (7): eal: split atomic operations to architecture specific eal: split byte order operations to architecture specific eal: split CPU cycle operation to architecture specific eal: split prefetch operations to architecture specific eal: split spinlock operations to architecture specific eal: split memcpy operation to architecture specific eal: split CPU flags operations to architecture specific David Marchand (3): eal: move rte_atomic.h header eal: install all arch headers eal: factorize x86 headers doc/api/doxy-api.conf |1 + lib/librte_eal/common/Makefile | 24 +- lib/librte_eal/common/eal_common_cpuflags.c| 190 .../common/include/arch/x86/rte_atomic.h | 216 .../common/include/arch/x86/rte_atomic_32.h| 222 .../common/include/arch/x86/rte_atomic_64.h| 191 .../common/include/arch/x86/rte_byteorder.h| 121 +++ .../common/include/arch/x86/rte_byteorder_32.h | 51 + .../common/include/arch/x86/rte_byteorder_64.h | 52 + .../common/include/arch/x86/rte_cpuflags.h | 310 ++ .../common/include/arch/x86/rte_cycles.h | 121 +++ .../common/include/arch/x86/rte_memcpy.h | 297 + .../common/include/arch/x86/rte_prefetch.h | 62 ++ .../common/include/arch/x86/rte_spinlock.h | 94 ++ lib/librte_eal/common/include/generic/rte_atomic.h | 918 .../common/include/generic/rte_byteorder.h | 189 .../common/include/generic/rte_cpuflags.h | 110 ++ lib/librte_eal/common/include/generic/rte_cycles.h | 209 lib/librte_eal/common/include/generic/rte_memcpy.h | 144 +++ .../common/include/generic/rte_prefetch.h | 71 ++ .../common/include/generic/rte_spinlock.h | 226 .../common/include/i686/arch/rte_atomic.h | 373 --- lib/librte_eal/common/include/rte_atomic.h | 1133 lib/librte_eal/common/include/rte_byteorder.h | 270 - lib/librte_eal/common/include/rte_cpuflags.h | 182 lib/librte_eal/common/include/rte_cycles.h | 266 - lib/librte_eal/common/include/rte_memcpy.h | 376 --- lib/librte_eal/common/include/rte_prefetch.h | 88 -- lib/librte_eal/common/include/rte_spinlock.h | 258 - .../common/include/x86_64/arch/rte_atomic.h| 335 -- mk/arch/i686/rte.vars.mk |2 + mk/arch/x86_64/rte.vars.mk |2 + 32 files changed, 3624 insertions(+), 3480 deletions(-) create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic_32.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic_64.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder_32.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder_64.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_cpuflags.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_cycles.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_memcpy.h create mod
[dpdk-dev] [PATCH v3 01/10] eal: move rte_atomic.h header
This breaks compilation but is a preliminary step for headers rework.
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/arch/i686/rte_atomic.h | 373
.../common/include/arch/x86_64/rte_atomic.h| 335 ++
.../common/include/i686/arch/rte_atomic.h | 373
.../common/include/x86_64/arch/rte_atomic.h| 335 --
5 files changed, 710 insertions(+), 710 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_atomic.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_atomic.h
delete mode 100644 lib/librte_eal/common/include/i686/arch/rte_atomic.h
delete mode 100644 lib/librte_eal/common/include/x86_64/arch/rte_atomic.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 7f27966..6603c61 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -49,8 +49,8 @@ endif
ARCH_INC := rte_atomic.h
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
-SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include/arch := \
- $(addprefix include/$(RTE_ARCH)/arch/,$(ARCH_INC))
+SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include += \
+ $(addprefix include/arch/$(RTE_ARCH)/,$(ARCH_INC))
# add libc if configured
DEPDIRS-$(CONFIG_RTE_LIBC) += lib/libc
diff --git a/lib/librte_eal/common/include/arch/i686/rte_atomic.h
b/lib/librte_eal/common/include/arch/i686/rte_atomic.h
new file mode 100644
index 000..6956b87
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/i686/rte_atomic.h
@@ -0,0 +1,373 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/*
+ * Inspired from FreeBSD src/sys/i386/include/atomic.h
+ * Copyright (c) 1998 Doug Rabson
+ * All rights reserved.
+ */
+
+#ifndef _RTE_ATOMIC_H_
+#error "don't include this file directly, please include generic
"
+#endif
+
+#ifndef _RTE_I686_ATOMIC_H_
+#define _RTE_I686_ATOMIC_H_
+
+
+/**
+ * @file
+ * Atomic Operations on i686
+ */
+
+
+/*- 64 bit atomic operations
-*/
+
+/**
+ * An atomic compare and set function used by the mutex functions.
+ * (atomic) equivalent to:
+ * if (*dst == exp)
+ * *dst = src (all 64-bit words)
+ *
+ * @param dst
+ * The destination into which the value will be written.
+ * @param exp
+ * The expected value.
+ * @param src
+ * The new value.
+ * @return
+ * Non-zero on success; 0 on failure.
+ */
+static inline int
+rte_atomic64_cmpset(volatile uint64_t *dst, uint64_t exp, uint64_t src)
+{
+ uint8_t res;
+ union {
+ struct {
+ uint32_t l32;
+ uint32_t h32;
+ };
+ uint64_t u64;
+ } _exp, _src;
+
+ _exp.u64 = exp;
+ _src.u64 = src;
+
+#ifndef __PIC__
+asm volatile (
+MPLOCKED
+"cmpxchg8b (%[dst]);"
+"setz %[res];"
+: [res] "=a" (res) /* result in eax */
+: [dst] "S" (dst), /* esi */
+ "b" (_src.l32), /* ebx */
+ "c" (_src.h32), /* ecx */
+ "a" (_exp.l32), /* eax */
+ "d" (_exp.h32)/* edx */
+
[dpdk-dev] [PATCH v3 02/10] eal: split atomic operations to architecture specific
From: Chao Zhu
This patch first adds architecture specific directories to eal.
Then split the atomic operations to architecture specific and generic files.
Architecture specific files are put into the corresponding architecture
directory and common header are put into generic directory.
Update documentation generation with new generic/ directory.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
doc/api/doxy-api.conf |1 +
lib/librte_eal/common/Makefile |7 +-
.../common/include/arch/i686/rte_atomic.h | 322 +++---
.../common/include/arch/x86_64/rte_atomic.h| 321 +++---
lib/librte_eal/common/include/generic/rte_atomic.h | 918
lib/librte_eal/common/include/rte_atomic.h | 1133
6 files changed, 1269 insertions(+), 1433 deletions(-)
create mode 100644 lib/librte_eal/common/include/generic/rte_atomic.h
delete mode 100644 lib/librte_eal/common/include/rte_atomic.h
diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf
index fe3879f..27c782c 100644
--- a/doc/api/doxy-api.conf
+++ b/doc/api/doxy-api.conf
@@ -31,6 +31,7 @@
PROJECT_NAME= DPDK
INPUT = doc/api/doxy-api-index.md \
lib/librte_eal/common/include \
+ lib/librte_eal/common/include/generic \
lib/librte_acl \
lib/librte_distributor \
lib/librte_ether \
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 6603c61..8ab363b 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -31,7 +31,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
-INC := rte_atomic.h rte_branch_prediction.h rte_byteorder.h rte_common.h
+INC := rte_branch_prediction.h rte_byteorder.h rte_common.h
INC += rte_cycles.h rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_prefetch.h rte_random.h
@@ -46,11 +46,14 @@ ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y)
INC += rte_warnings.h
endif
-ARCH_INC := rte_atomic.h
+GENERIC_INC := rte_atomic.h
+ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include += \
$(addprefix include/arch/$(RTE_ARCH)/,$(ARCH_INC))
+SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include/generic := \
+ $(addprefix include/generic/,$(GENERIC_INC))
# add libc if configured
DEPDIRS-$(CONFIG_RTE_LIBC) += lib/libc
diff --git a/lib/librte_eal/common/include/arch/i686/rte_atomic.h
b/lib/librte_eal/common/include/arch/i686/rte_atomic.h
index 6956b87..8330250 100644
--- a/lib/librte_eal/common/include/arch/i686/rte_atomic.h
+++ b/lib/librte_eal/common/include/arch/i686/rte_atomic.h
@@ -37,37 +37,179 @@
* All rights reserved.
*/
-#ifndef _RTE_ATOMIC_H_
-#error "don't include this file directly, please include generic
"
+#ifndef _RTE_ATOMIC_I686_H_
+#define _RTE_ATOMIC_I686_H_
+
+#ifdef __cplusplus
+extern "C" {
#endif
-#ifndef _RTE_I686_ATOMIC_H_
-#define _RTE_I686_ATOMIC_H_
+#include
+#include "generic/rte_atomic.h"
+#if RTE_MAX_LCORE == 1
+#define MPLOCKED/**< No need to insert MP lock prefix.
*/
+#else
+#define MPLOCKED"lock ; " /**< Insert MP lock prefix. */
+#endif
-/**
- * @file
- * Atomic Operations on i686
- */
+#definerte_mb() _mm_mfence()
+
+#definerte_wmb() _mm_sfence()
+
+#definerte_rmb() _mm_lfence()
+
+/*- 16 bit atomic operations
-*/
+
+#ifndef RTE_FORCE_INTRINSICS
+static inline int
+rte_atomic16_cmpset(volatile uint16_t *dst, uint16_t exp, uint16_t src)
+{
+ uint8_t res;
+
+ asm volatile(
+ MPLOCKED
+ "cmpxchgw %[src], %[dst];"
+ "sete %[res];"
+ : [res] "=a" (res), /* output */
+ [dst] "=m" (*dst)
+ : [src] "r" (src), /* input */
+ "a" (exp),
+ "m" (*dst)
+ : "memory");/* no-clobber list */
+ return res;
+}
+
+static inline int rte_atomic16_test_and_set(rte_atomic16_t *v)
+{
+ return rte_atomic16_cmpset((volatile uint16_t *)&v->cnt, 0, 1);
+}
+
+static inline void
+rte_atomic16_inc(rte_atomic16_t *v)
+{
+ asm volatile(
+ MPLOCKED
+ "incw %[cnt]"
+ : [cnt] "=m" (v->cnt) /* output */
+ : "m" (v->cnt) /* input */
+ );
+}
+
+static inline void
+rte_atomic16_dec(rte_atomic16_t *v)
+{
+ asm volatile(
+ MPLOCKED
+ "decw %[cnt]"
+ : [cnt] "=
[dpdk-dev] [PATCH v3 03/10] eal: split byte order operations to architecture specific
From: Chao Zhu
This patch splits the byte order operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can be easily adopted.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/arch/i686/rte_byteorder.h | 129 ++
.../common/include/arch/x86_64/rte_byteorder.h | 130 ++
.../common/include/generic/rte_byteorder.h | 189 ++
lib/librte_eal/common/include/rte_byteorder.h | 270
5 files changed, 450 insertions(+), 272 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_byteorder.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_byteorder.h
create mode 100644 lib/librte_eal/common/include/generic/rte_byteorder.h
delete mode 100644 lib/librte_eal/common/include/rte_byteorder.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 8ab363b..62a39cd 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -31,7 +31,7 @@
include $(RTE_SDK)/mk/rte.vars.mk
-INC := rte_branch_prediction.h rte_byteorder.h rte_common.h
+INC := rte_branch_prediction.h rte_common.h
INC += rte_cycles.h rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_prefetch.h rte_random.h
@@ -46,7 +46,7 @@ ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y)
INC += rte_warnings.h
endif
-GENERIC_INC := rte_atomic.h
+GENERIC_INC := rte_atomic.h rte_byteorder.h
ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
diff --git a/lib/librte_eal/common/include/arch/i686/rte_byteorder.h
b/lib/librte_eal/common/include/arch/i686/rte_byteorder.h
new file mode 100644
index 000..6d5b23e
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/i686/rte_byteorder.h
@@ -0,0 +1,129 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_BYTEORDER_I686_H_
+#define _RTE_BYTEORDER_I686_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_byteorder.h"
+
+/*
+ * An architecture-optimized byte swap for a 16-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap16().
+ */
+static inline uint16_t rte_arch_bswap16(uint16_t _x)
+{
+ register uint16_t x = _x;
+ asm volatile ("xchgb %b[x1],%h[x2]"
+ : [x1] "=Q" (x)
+ : [x2] "0" (x)
+ );
+ return x;
+}
+
+/*
+ * An architecture-optimized byte swap for a 32-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap32().
+ */
+static inline uint32_t rte_arch_bswap32(uint32_t _x)
+{
+ register uint32_t x = _x;
+ asm volatile ("bswap %[x]"
+ : [x] "+r" (x)
+ );
+ return x;
+}
+
+/*
+ * An architecture-optimized byte swap for a 64-bit value.
+ *
+ * Do not use this function directly. The preferred function is rte_bswap64().
+ */
+/* Compat./Leg. mode */
+static inline uint64_t rte_arch_bswap64(uint64_t x)
+{
+ uint64_t ret = 0;
+ ret |= ((
[dpdk-dev] [PATCH v3 04/10] eal: split CPU cycle operation to architecture specific
From: Chao Zhu This patch splits the CPU TSC read operations from DPDK and push them to architecture specific arch directories, so that other processors that don't have tsc register can implement its own functions. Signed-off-by: Chao Zhu Signed-off-by: David Marchand --- lib/librte_eal/common/Makefile |4 +- .../common/include/arch/i686/rte_cycles.h | 121 + .../common/include/arch/x86_64/rte_cycles.h| 121 + lib/librte_eal/common/include/generic/rte_cycles.h | 209 +++ lib/librte_eal/common/include/rte_cycles.h | 266 5 files changed, 453 insertions(+), 268 deletions(-) create mode 100644 lib/librte_eal/common/include/arch/i686/rte_cycles.h create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_cycles.h create mode 100644 lib/librte_eal/common/include/generic/rte_cycles.h delete mode 100644 lib/librte_eal/common/include/rte_cycles.h diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile index 62a39cd..c6aedf9 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -32,7 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk INC := rte_branch_prediction.h rte_common.h -INC += rte_cycles.h rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h +INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h INC += rte_pci_dev_ids.h rte_per_lcore.h rte_prefetch.h rte_random.h INC += rte_rwlock.h rte_spinlock.h rte_tailq.h rte_interrupts.h rte_alarm.h @@ -46,7 +46,7 @@ ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y) INC += rte_warnings.h endif -GENERIC_INC := rte_atomic.h rte_byteorder.h +GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h ARCH_INC := $(GENERIC_INC) SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC)) diff --git a/lib/librte_eal/common/include/arch/i686/rte_cycles.h b/lib/librte_eal/common/include/arch/i686/rte_cycles.h new file mode 100644 index 000..6e47040 --- /dev/null +++ b/lib/librte_eal/common/include/arch/i686/rte_cycles.h @@ -0,0 +1,121 @@ +/*- + * BSD LICENSE + * + * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of Intel Corporation nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT + * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE + * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ +/* BSD LICENSE + * + * Copyright(c) 2013 6WIND. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * * Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * * Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in + * the documentation and/or other materials provided with the + * distribution. + * * Neither the name of 6WIND S.A. nor the names of its + * contributors may be used to endorse or promote products derived + * from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR + * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SH
[dpdk-dev] [PATCH v3 05/10] eal: split prefetch operations to architecture specific
From: Chao Zhu
This patch splits the prefetch operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can implement their own functions.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/arch/i686/rte_prefetch.h| 62 ++
.../common/include/arch/x86_64/rte_prefetch.h | 62 ++
.../common/include/generic/rte_prefetch.h | 71
lib/librte_eal/common/include/rte_prefetch.h | 88
5 files changed, 197 insertions(+), 90 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_prefetch.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_prefetch.h
create mode 100644 lib/librte_eal/common/include/generic/rte_prefetch.h
delete mode 100644 lib/librte_eal/common/include/rte_prefetch.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index c6aedf9..9808c9f 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -34,7 +34,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
INC := rte_branch_prediction.h rte_common.h
INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h
-INC += rte_pci_dev_ids.h rte_per_lcore.h rte_prefetch.h rte_random.h
+INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
INC += rte_rwlock.h rte_spinlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
INC += rte_string_fns.h rte_cpuflags.h rte_version.h rte_tailq_elem.h
INC += rte_eal_memconfig.h rte_malloc_heap.h
@@ -46,7 +46,7 @@ ifeq ($(CONFIG_RTE_INSECURE_FUNCTION_WARNING),y)
INC += rte_warnings.h
endif
-GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h
+GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
diff --git a/lib/librte_eal/common/include/arch/i686/rte_prefetch.h
b/lib/librte_eal/common/include/arch/i686/rte_prefetch.h
new file mode 100644
index 000..5fbd98e
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/i686/rte_prefetch.h
@@ -0,0 +1,62 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_PREFETCH_I686_H_
+#define _RTE_PREFETCH_I686_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_prefetch.h"
+
+static inline void rte_prefetch0(volatile void *p)
+{
+ asm volatile ("prefetcht0 %[p]" : [p] "+m" (*(volatile char *)p));
+}
+
+static inline void rte_prefetch1(volatile void *p)
+{
+ asm volatile ("prefetcht1 %[p]" : [p] "+m" (*(volatile char *)p));
+}
+
+static inline void rte_prefetch2(volatile void *p)
+{
+ asm volatile ("prefetcht2 %[p]" : [p] "+m" (*(volatile char *)p));
+}
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _RTE_PREFETCH_I686_H_ */
diff --git a/lib/librte_eal/common/include/arch/x86_64/rte_prefetch.h
b/lib/librte_eal/common/include/arch/x86_64/rte_prefetch.h
new file mode 100644
index 000..ec2454d
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/x86_64/rte_prefetch.h
@@ -0,0 +1,62 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation.
[dpdk-dev] [PATCH v3 06/10] eal: split spinlock operations to architecture specific
From: Chao Zhu
This patch splits the spinlock operations from DPDK and push them to
architecture specific arch directories, so that other processor
architecture to support DPDK can be easily adopted.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |3 +-
.../common/include/arch/i686/rte_spinlock.h| 94 +++
.../common/include/arch/x86_64/rte_spinlock.h | 94 +++
.../common/include/generic/rte_spinlock.h | 226 +
lib/librte_eal/common/include/rte_spinlock.h | 258
5 files changed, 416 insertions(+), 259 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_spinlock.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_spinlock.h
create mode 100644 lib/librte_eal/common/include/generic/rte_spinlock.h
delete mode 100644 lib/librte_eal/common/include/rte_spinlock.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 9808c9f..2394443 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -35,7 +35,7 @@ INC := rte_branch_prediction.h rte_common.h
INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
-INC += rte_rwlock.h rte_spinlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
+INC += rte_rwlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
INC += rte_string_fns.h rte_cpuflags.h rte_version.h rte_tailq_elem.h
INC += rte_eal_memconfig.h rte_malloc_heap.h
INC += rte_hexdump.h rte_devargs.h rte_dev.h
@@ -47,6 +47,7 @@ INC += rte_warnings.h
endif
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
+GENERIC_INC += rte_spinlock.h
ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
diff --git a/lib/librte_eal/common/include/arch/i686/rte_spinlock.h
b/lib/librte_eal/common/include/arch/i686/rte_spinlock.h
new file mode 100644
index 000..60cfd4d
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/i686/rte_spinlock.h
@@ -0,0 +1,94 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_SPINLOCK_I686_H_
+#define _RTE_SPINLOCK_I686_H_
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_spinlock.h"
+
+#ifndef RTE_FORCE_INTRINSICS
+static inline void
+rte_spinlock_lock(rte_spinlock_t *sl)
+{
+ int lock_val = 1;
+ asm volatile (
+ "1:\n"
+ "xchg %[locked], %[lv]\n"
+ "test %[lv], %[lv]\n"
+ "jz 3f\n"
+ "2:\n"
+ "pause\n"
+ "cmpl $0, %[locked]\n"
+ "jnz 2b\n"
+ "jmp 1b\n"
+ "3:\n"
+ : [locked] "=m" (sl->locked), [lv] "=q" (lock_val)
+ : "[lv]" (lock_val)
+ : "memory");
+}
+
+static inline void
+rte_spinlock_unlock (rte_spinlock_t *sl)
+{
+ int unlock_val = 0;
+ asm volatile (
+ "xchg %[locked], %[ulv]\n"
+ : [locked] "=m" (sl->locked), [ulv] "=q" (unloc
[dpdk-dev] [PATCH v3 08/10] eal: split CPU flags operations to architecture specific
From: Chao Zhu
This patch splits CPU flags related operations from DPDK and push them
to architecture specific arch directories, so that other processor
architecture can implement its own CPU flag functions to support DPDK.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |4 +-
lib/librte_eal/common/eal_common_cpuflags.c| 190
.../common/include/arch/i686/rte_cpuflags.h| 310
.../common/include/arch/x86_64/rte_cpuflags.h | 310
.../common/include/generic/rte_cpuflags.h | 110 +++
lib/librte_eal/common/include/rte_cpuflags.h | 182
6 files changed, 732 insertions(+), 374 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_cpuflags.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_cpuflags.h
create mode 100644 lib/librte_eal/common/include/generic/rte_cpuflags.h
delete mode 100644 lib/librte_eal/common/include/rte_cpuflags.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index f9f98dc..ddf8b48 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -36,7 +36,7 @@ INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h
rte_lcore.h
INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
INC += rte_rwlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
-INC += rte_string_fns.h rte_cpuflags.h rte_version.h rte_tailq_elem.h
+INC += rte_string_fns.h rte_version.h rte_tailq_elem.h
INC += rte_eal_memconfig.h rte_malloc_heap.h
INC += rte_hexdump.h rte_devargs.h rte_dev.h
INC += rte_common_vect.h
@@ -47,7 +47,7 @@ INC += rte_warnings.h
endif
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
-GENERIC_INC += rte_spinlock.h rte_memcpy.h
+GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h
ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c
b/lib/librte_eal/common/eal_common_cpuflags.c
index 9e79179..6fd360c 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -30,10 +30,6 @@
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-#include
-#include
-#include
-#include
#include
/*
@@ -50,192 +46,6 @@
#endif
/**
- * Enumeration of CPU registers
- */
-enum cpu_register_t {
- REG_EAX = 0,
- REG_EBX,
- REG_ECX,
- REG_EDX,
-};
-
-typedef uint32_t cpuid_registers_t[4];
-
-#define CPU_FLAG_NAME_MAX_LEN 64
-
-/**
- * Struct to hold a processor feature entry
- */
-struct feature_entry {
- uint32_t leaf; /**< cpuid leaf */
- uint32_t subleaf; /**< cpuid subleaf */
- uint32_t reg; /**< cpuid register */
- uint32_t bit; /**< cpuid register bit */
- char name[CPU_FLAG_NAME_MAX_LEN]; /**< String for printing */
-};
-
-#define FEAT_DEF(name, leaf, subleaf, reg, bit) \
- [RTE_CPUFLAG_##name] = {leaf, subleaf, reg, bit, #name },
-
-/**
- * An array that holds feature entries
- */
-static const struct feature_entry cpu_feature_table[] = {
- FEAT_DEF(SSE3, 0x0001, 0, REG_ECX, 0)
- FEAT_DEF(PCLMULQDQ, 0x0001, 0, REG_ECX, 1)
- FEAT_DEF(DTES64, 0x0001, 0, REG_ECX, 2)
- FEAT_DEF(MONITOR, 0x0001, 0, REG_ECX, 3)
- FEAT_DEF(DS_CPL, 0x0001, 0, REG_ECX, 4)
- FEAT_DEF(VMX, 0x0001, 0, REG_ECX, 5)
- FEAT_DEF(SMX, 0x0001, 0, REG_ECX, 6)
- FEAT_DEF(EIST, 0x0001, 0, REG_ECX, 7)
- FEAT_DEF(TM2, 0x0001, 0, REG_ECX, 8)
- FEAT_DEF(SSSE3, 0x0001, 0, REG_ECX, 9)
- FEAT_DEF(CNXT_ID, 0x0001, 0, REG_ECX, 10)
- FEAT_DEF(FMA, 0x0001, 0, REG_ECX, 12)
- FEAT_DEF(CMPXCHG16B, 0x0001, 0, REG_ECX, 13)
- FEAT_DEF(XTPR, 0x0001, 0, REG_ECX, 14)
- FEAT_DEF(PDCM, 0x0001, 0, REG_ECX, 15)
- FEAT_DEF(PCID, 0x0001, 0, REG_ECX, 17)
- FEAT_DEF(DCA, 0x0001, 0, REG_ECX, 18)
- FEAT_DEF(SSE4_1, 0x0001, 0, REG_ECX, 19)
- FEAT_DEF(SSE4_2, 0x0001, 0, REG_ECX, 20)
- FEAT_DEF(X2APIC, 0x0001, 0, REG_ECX, 21)
- FEAT_DEF(MOVBE, 0x0001, 0, REG_ECX, 22)
- FEAT_DEF(POPCNT, 0x0001, 0, REG_ECX, 23)
- FEAT_DEF(TSC_DEADLINE, 0x0001, 0, REG_ECX, 24)
- FEAT_DEF(AES, 0x0001, 0, REG_ECX, 25)
- FEAT_DEF(XSAVE, 0x0001, 0, REG_ECX, 26)
- FEAT_DEF(OSXSAVE, 0x0001, 0, REG_ECX, 27)
- FEAT_DEF(AVX, 0x0001, 0, REG_ECX, 28)
- FEAT_DEF(F16C, 0x0001, 0, REG_ECX, 29)
- FEAT_DEF(RDRAND, 0x0001, 0, REG_ECX, 30)
-
- FEAT_
[dpdk-dev] [PATCH v3 07/10] eal: split memcpy operation to architecture specific
From: Chao Zhu
This patch splits the SSE based memory copy function from DPDK and push
them to architecture specific arch directories. Other processor
architecture can implement its own vector based memory copy functions.
Signed-off-by: Chao Zhu
Signed-off-by: David Marchand
---
lib/librte_eal/common/Makefile |4 +-
.../common/include/arch/i686/rte_memcpy.h | 297
.../common/include/arch/x86_64/rte_memcpy.h| 297
lib/librte_eal/common/include/generic/rte_memcpy.h | 144
lib/librte_eal/common/include/rte_memcpy.h | 376
5 files changed, 740 insertions(+), 378 deletions(-)
create mode 100644 lib/librte_eal/common/include/arch/i686/rte_memcpy.h
create mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_memcpy.h
create mode 100644 lib/librte_eal/common/include/generic/rte_memcpy.h
delete mode 100644 lib/librte_eal/common/include/rte_memcpy.h
diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile
index 2394443..f9f98dc 100644
--- a/lib/librte_eal/common/Makefile
+++ b/lib/librte_eal/common/Makefile
@@ -33,7 +33,7 @@ include $(RTE_SDK)/mk/rte.vars.mk
INC := rte_branch_prediction.h rte_common.h
INC += rte_debug.h rte_eal.h rte_errno.h rte_launch.h rte_lcore.h
-INC += rte_log.h rte_memcpy.h rte_memory.h rte_memzone.h rte_pci.h
+INC += rte_log.h rte_memory.h rte_memzone.h rte_pci.h
INC += rte_pci_dev_ids.h rte_per_lcore.h rte_random.h
INC += rte_rwlock.h rte_tailq.h rte_interrupts.h rte_alarm.h
INC += rte_string_fns.h rte_cpuflags.h rte_version.h rte_tailq_elem.h
@@ -47,7 +47,7 @@ INC += rte_warnings.h
endif
GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h
-GENERIC_INC += rte_spinlock.h
+GENERIC_INC += rte_spinlock.h rte_memcpy.h
ARCH_INC := $(GENERIC_INC)
SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC))
diff --git a/lib/librte_eal/common/include/arch/i686/rte_memcpy.h
b/lib/librte_eal/common/include/arch/i686/rte_memcpy.h
new file mode 100644
index 000..b8513f6
--- /dev/null
+++ b/lib/librte_eal/common/include/arch/i686/rte_memcpy.h
@@ -0,0 +1,297 @@
+/*-
+ * BSD LICENSE
+ *
+ * Copyright(c) 2010-2014 Intel Corporation. All rights reserved.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _RTE_MEMCPY_I686_H_
+#define _RTE_MEMCPY_I686_H_
+
+#include
+#include
+#include
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include "generic/rte_memcpy.h"
+
+#ifdef __INTEL_COMPILER
+#pragma warning(disable:593) /* Stop unused variable warning (reg_a etc). */
+#endif
+
+static inline void
+rte_mov16(uint8_t *dst, const uint8_t *src)
+{
+ __m128i reg_a;
+ asm volatile (
+ "movdqu (%[src]), %[reg_a]\n\t"
+ "movdqu %[reg_a], (%[dst])\n\t"
+ : [reg_a] "=x" (reg_a)
+ : [src] "r" (src),
+ [dst] "r"(dst)
+ : "memory"
+ );
+}
+
+static inline void
+rte_mov32(uint8_t *dst, const uint8_t *src)
+{
+ __m128i reg_a, reg_b;
+ asm volatile (
+ "movdqu (%[src]), %[reg_a]\n\t"
+ "movdqu 16(%[src]), %[reg_b]\n\t"
+ "movdqu %[reg_a], (%[dst])\n\t"
+ "movdqu %[reg_b], 16(%[dst])\n\t"
+ : [reg_a] "=x" (reg_a),
+ [reg_b] "=x" (reg_b)
+ : [src] "r" (src
[dpdk-dev] [PATCH v3 09/10] eal: install all arch headers
Architecture can have their own specific headers, just install all headers from arch directory. Signed-off-by: David Marchand --- lib/librte_eal/common/Makefile |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/librte_eal/common/Makefile b/lib/librte_eal/common/Makefile index ddf8b48..499ba4d 100644 --- a/lib/librte_eal/common/Makefile +++ b/lib/librte_eal/common/Makefile @@ -48,11 +48,13 @@ endif GENERIC_INC := rte_atomic.h rte_byteorder.h rte_cycles.h rte_prefetch.h GENERIC_INC += rte_spinlock.h rte_memcpy.h rte_cpuflags.h -ARCH_INC := $(GENERIC_INC) +# defined in mk/arch/$(RTE_ARCH)/rte.vars.mk +ARCH_DIR ?= $(RTE_ARCH) +ARCH_INC := $(notdir $(wildcard $(RTE_SDK)/lib/librte_eal/common/include/arch/$(ARCH_DIR)/*.h)) SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include := $(addprefix include/,$(INC)) SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include += \ - $(addprefix include/arch/$(RTE_ARCH)/,$(ARCH_INC)) + $(addprefix include/arch/$(ARCH_DIR)/,$(ARCH_INC)) SYMLINK-$(CONFIG_RTE_LIBRTE_EAL)-include/generic := \ $(addprefix include/generic/,$(GENERIC_INC)) -- 1.7.10.4
[dpdk-dev] [PATCH v3 10/10] eal: factorize x86 headers
No need to keep the same code duplicated for 32 and 64bits x86. Signed-off-by: David Marchand --- .../common/include/arch/i686/rte_atomic.h | 393 .../common/include/arch/i686/rte_byteorder.h | 129 --- .../common/include/arch/i686/rte_cpuflags.h| 310 --- .../common/include/arch/i686/rte_cycles.h | 121 -- .../common/include/arch/i686/rte_memcpy.h | 297 --- .../common/include/arch/i686/rte_prefetch.h| 62 --- .../common/include/arch/i686/rte_spinlock.h| 94 - .../common/include/arch/x86/rte_atomic.h | 216 +++ .../common/include/arch/x86/rte_atomic_32.h| 222 +++ .../common/include/arch/x86/rte_atomic_64.h| 191 ++ .../common/include/arch/x86/rte_byteorder.h| 121 ++ .../common/include/arch/x86/rte_byteorder_32.h | 51 +++ .../common/include/arch/x86/rte_byteorder_64.h | 52 +++ .../common/include/arch/x86/rte_cpuflags.h | 310 +++ .../common/include/arch/x86/rte_cycles.h | 121 ++ .../common/include/arch/x86/rte_memcpy.h | 297 +++ .../common/include/arch/x86/rte_prefetch.h | 62 +++ .../common/include/arch/x86/rte_spinlock.h | 94 + .../common/include/arch/x86_64/rte_atomic.h| 362 -- .../common/include/arch/x86_64/rte_byteorder.h | 130 --- .../common/include/arch/x86_64/rte_cpuflags.h | 310 --- .../common/include/arch/x86_64/rte_cycles.h| 121 -- .../common/include/arch/x86_64/rte_memcpy.h| 297 --- .../common/include/arch/x86_64/rte_prefetch.h | 62 --- .../common/include/arch/x86_64/rte_spinlock.h | 94 - mk/arch/i686/rte.vars.mk |2 + mk/arch/x86_64/rte.vars.mk |2 + 27 files changed, 1741 insertions(+), 2782 deletions(-) delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_atomic.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_byteorder.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_cpuflags.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_cycles.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_memcpy.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_prefetch.h delete mode 100644 lib/librte_eal/common/include/arch/i686/rte_spinlock.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic_32.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_atomic_64.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder_32.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_byteorder_64.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_cpuflags.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_cycles.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_memcpy.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_prefetch.h create mode 100644 lib/librte_eal/common/include/arch/x86/rte_spinlock.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_atomic.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_byteorder.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_cpuflags.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_cycles.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_memcpy.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_prefetch.h delete mode 100644 lib/librte_eal/common/include/arch/x86_64/rte_spinlock.h diff --git a/lib/librte_eal/common/include/arch/i686/rte_atomic.h b/lib/librte_eal/common/include/arch/i686/rte_atomic.h deleted file mode 100644 index 8330250..000 --- a/lib/librte_eal/common/include/arch/i686/rte_atomic.h +++ /dev/null @@ -1,393 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2014 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials provided with the - * distribution. - * * Neither the name of Intel Corporation nor the names of its - * contributors may be used to endorse or promote products derived - * from this software witho
[dpdk-dev] [PATCH v4 04/21] ethdev: define structures for adding/deleting flow director
2014-10-28 01:18, Wu, Jingjing:
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > 2014-10-22 09:01, Jingjing Wu:
> > > +#define RTE_ETH_FDIR_MAX_FLEXWORD_LEN 8
> > > +/**
> > > + * A structure used to contain extend input of flow */ struct
> > > +rte_eth_fdir_flow_ext {
> > > + uint16_t vlan_tci;
> > > + uint8_t num_flexwords; /**< number of flexwords */
> > > + uint16_t flexwords[RTE_ETH_FDIR_MAX_FLEXWORD_LEN];
> > > + uint16_t dest_id; /**< destination vsi or pool id*/
> > > +};
> >
> > Flexword should be explained.
> >
> The flexword means the application can choose a part of packet's payload
> as key words to compare match. It is flexible.
> In Ixgbe, the flexwords is 1 word (2 bytes), while Fortville extend it to 8
> words.
OK. The problem is that I don't know how to fill the flexwords bytes.
You should explain it in the doxygen comment.
You say it's flexible. Is it usable with a non-IP packet?
Please explain constraints and syntax.
> > > +struct rte_eth_fdir_input {
> > > + enum rte_eth_flow_type flow_type; /**< type of flow */
> > > + union rte_eth_fdir_flow flow; /**< specific flow structure */
> > > + struct rte_eth_fdir_flow_ext flow_ext; /**< specific flow info */ };
> >
> > I don't understand the logic behind flow/flow_ext.
> > Why flow_ext is not merged into flow ?
> >
> The flow defines the key words for each flow_type, while the flow_ext
> has other elements which have little to do with flow_type.
> For example the flexword, dst_id (can used as pool id), I think it is not
> reasonable to make it as an element in the flow.
Sorry, I don't understand.
flow and flow_ext are associated with a flow type.
The comments are "specific flow structure" and "specific flow info" which
doesn't bring any useful information.
> > > +/**
> > > + * Flow director report status
> > > + */
> > > +enum rte_eth_fdir_status {
> > > + RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< no report FDIR. */
> > > + RTE_ETH_FDIR_REPORT_FD_ID, /**< only report FD ID. */
> > > + RTE_ETH_FDIR_REPORT_FD_ID_FLEX_4, /**< report FD ID and 4 flex bytes.
> > > */
> > > + RTE_ETH_FDIR_REPORT_FLEX_8,/**< report 8 flex bytes. */
> > > +};
> >
> > The names and explanations are cryptics.
>
> The enum defines what will be reported when FIR match.
> Can be FD_ID or flex bytes
Just to be sure, have you understood that I'm requesting more explanations
in the comments to allow users of your API to understand it?
> > > +/**
> > > + * A structure used to define an action when match FDIR packet filter.
> > > + */
> > > +struct rte_eth_fdir_action {
> > > + uint16_t rx_queue;/**< queue assigned to if fdir match. */
> > > + uint16_t cnt_idx; /**< statistic counter index */
> >
> > what is the action of "statistic counter index"?
>
> When FD match happened, the counter will increase.
Which counter?
Which value should be set in cnt_idx?
> Fortville can support to configure the different counter for filter entries.
> The action is a part of a filter entry, so this element means which counter
> the entry will use.
I perfectly understand that you are writing some code to allow usage of
Fortville features through DPDK. Thank you for bringing new features.
But I want to know if I'm allowed to use it without reading the Fortville
datasheet?
And could this API be shared by other hardwares (e.g. ixgbe)?
> > > + uint8_t drop;/**< accept or reject */
> > > + uint8_t flex_off;/**< offset used define words to report */
> >
> > still difficult to understand the flex logic
>
> Just as mentioned above, Fortville can support 8 flex words comparing.
> But for reporting, only 4 or 8 bytes in the flex words can be reported.
> So need to specify the offset to choose the 4 or 8 bytes.
I don't even know what are the meaning of these 4 or 8 bytes.
Please don't consider that every DPDK user know the Fortville datasheet.
> > > +/**
> > > + * A structure used to define the flow director filter entry by
> > > +filter_ctl API
> > > + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_ADD and
> > > + * RTE_ETH_FILTER_DELETE operations.
> > > + */
> > > +struct rte_eth_fdir_filter {
> > > + uint32_t soft_id; /**< id */
> >
> > Should the application handle the id numbering?
> > Why is it soft_id instead of id?
>
> Yes, the soft_id is just id, is also reported id when entry match.
> The id is specified by user, and can be used to identify this entry,
> application should handle it.
OK, so explain it in comments.
Or better, generate and return the id when creating a filter.
Thanks
--
Thomas
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
Hi Bruce > -Original Message- > From: Richardson, Bruce > Sent: Tuesday, October 28, 2014 6:18 PM > To: Thomas Monjalon; Zhang, Helin > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of > redirection table > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > Sent: Tuesday, October 28, 2014 10:10 AM > > To: Zhang, Helin > > Cc: dev at dpdk.org > > Subject: Re: [dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple > > sizes of redirection table > > > > 2014-10-28 00:33, Zhang, Helin: > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > 2014-09-25 16:40, Helin Zhang: > > > > > /* Definitions used for redirection table entry size */ > > > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > > +#define ETH_RSS_RETA_SIZE_64 64 #define ETH_RSS_RETA_SIZE_128 > > > > > +128 #define ETH_RSS_RETA_SIZE_512 512 > > > > > + > > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > > > Are these constants really needed? > > > > > > These constants were defined for the third input parameter of > > > rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End > > > users > > need > > > to give the correct reta size listed as above, as other values is > > > not valid. So it > > would be > > > better to list the valid reta sizes in macros here. > > > If only limited range of values are allowed, would an enum work better than a > set > of macros? Good idea! Any other comments for this from other guys? > > > OK, so you should explain that only these values are allowed. > > In general, it's something we explain in the comment of the function. > > > > By the way, why only these values are allowed? Regards, Helin
[dpdk-dev] [PATCH v4 06/21] testpmd: add test commands to add/delete flow director filter
2014-10-22 09:01, Jingjing Wu: > --- a/app/test-pmd/testpmd.h > +++ b/app/test-pmd/testpmd.h > @@ -73,6 +73,9 @@ int main(int argc, char **argv); > #define NUMA_NO_CONFIG 0xFF > #define UMA_NO_CONFIG 0xFF > > +#define BYTES_PER_WORD 2 This is an example of a constant which have a meaning. But it should be in lib/librte_eal/common/include/rte_common.h > +#define IPV6_ADDR_LEN 16 This one should be in lib/librte_net/rte_ip.h and should be used in ipv6_hdr. Thanks -- Thomas
[dpdk-dev] [PATCH v4 08/21] mbuf: extend fdir field
2014-10-22 09:01, Jingjing Wu:
> extend fdir field to support flex bytes reported when fdir match
The commit log should explain why it is required (i40e?).
It will help to understand when digging into git history of mbuf file.
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -171,8 +173,14 @@ struct rte_mbuf {
> union {
> uint32_t rss; /**< RSS hash result if RSS enabled */
> struct {
> - uint16_t hash;
> - uint16_t id;
> + union {
> + struct {
> + uint16_t hash;
> + uint16_t id;
> + };
> + uint32_t lo; /**< flexible bytes low*/
> + };
> + uint32_t hi; /**< flexible bytes high*/
> } fdir; /**< Filter identifier if FDIR enabled */
Please explain what could be the data of "flexible bytes high".
--
Thomas
[dpdk-dev] [PATCH v4 11/21] ethdev: define structures for getting flow director information
2014-10-22 09:01, Jingjing Wu:
> +/**
> + * A structure used to report the status of the flow director filters in use.
> + */
> +struct rte_eth_fdir {
> + /** Number of filters with collision indication. */
> + uint16_t collision;
> + /** Number of free (non programmed) filters. */
> + uint16_t free;
> + /** The Lookup hash value of the added filter that updated the value
> +of the MAXLEN field */
> + uint16_t maxhash;
> + /** Longest linked list of filters in the table. */
> + uint8_t maxlen;
> + /** Number of added filters. */
> + uint64_t add;
> + /** Number of removed filters. */
> + uint64_t remove;
> + /** Number of failed added filters (no more space in device). */
> + uint64_t f_add;
> + /** Number of failed removed filters. */
> + uint64_t f_remove;
> +};
rte_eth_fdir is a name which doesn't say what it really is.
This structure looks like a collection of statistics.
Why not rte_eth_fdir_stats?
> +struct rte_eth_fdir_ext {
> + uint16_t guarant_spc; /**< guaranteed spaces.*/
> + uint16_t guarant_cnt; /**< Number of filters in guaranteed spaces. */
> + uint16_t best_spc; /**< best effort spaces.*/
> + uint16_t best_cnt; /**< Number of filters in best effort spaces. */
> +};
I don't understand why this "extended" structure is not merged in the first one.
Adding new fields don't break old API.
> +/**
> + * A structure used to get the status information of flow director filter.
> + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_INFO operation.
> + */
OK content of this comment is good.
But the second sentence has no start.
Please try to have an uppercase letter at the beginning of your sentences,
and a subject followed by a verb.
(side note: this is also true for commit logs)
> +struct rte_eth_fdir_info {
> + int mode; /**< if 0 disbale, if 1 enable*/
Typo: disbale
--
Thomas
[dpdk-dev] [PATCH v4 15/21] testpmd: add test command to flush flow director table
2014-10-22 09:01, Jingjing Wu: > + "flush_flow_diretor (port_id)\n" Typo: diretor I know it's hard to write so much code in a small timeframe without any typo. Especially when you are not english native. But I'd like such simple errors would have been already reviewed after the fourth version of a patchset. -- Thomas
[dpdk-dev] [PATCH v4 16/21] ethdev: define structures for configuring flexible payload
2014-10-22 09:01, Jingjing Wu:
> +/**
> + * A structure defined a field vector to specify each field.
> + */
> +struct rte_eth_field_vector {
> + uint8_t offset; /**< Source word offset */
> + uint8_t size; /**< Field Size defined in word units */
> +};
I'm sorry but I don't understand this patch at all.
I think the reason is that I need more information about flex filter.
> +
> +/**
> + * payload type
> + */
> +enum rte_eth_payload_type {
> + RTE_ETH_PAYLOAD_UNKNOWN = 0,
> + RTE_ETH_L2_PAYLOAD,
> + RTE_ETH_L3_PAYLOAD,
> + RTE_ETH_L4_PAYLOAD,
> +};
> +
> /**
> * flow type
> */
> @@ -92,6 +111,30 @@ enum rte_eth_flow_type {
> };
>
> /**
> + * A structure used to select fields extracted from the protocol layers to
> + * the Field Vector as flexible payload for filter
> + */
> +struct rte_eth_flex_payload_cfg {
> + enum rte_eth_payload_type type; /**< payload type */
> + uint8_t nb_field;/**< the number of following fields */
> + struct rte_eth_field_vector field[0];
> +};
> +
> +#define RTE_ETH_FDIR_CFG_FLX 0x0001
> +/**
> + * A structure used to config FDIR filter global set
> + * to support RTE_ETH_FILTER_FDIR with RTE_ETH_FILTER_SET operation.
> + */
> +struct rte_eth_fdir_cfg {
> + uint16_t cmd; /**< sub command */
> + /**
> + * A pointer to structure for the configuration e.g.
> + * struct rte_eth_flex_payload_cfg for FDIR_CFG_FLX
> + */
> + void *cfg;
> +};
[dpdk-dev] [PATCH v4 21/21] testpmd: add test command to configure flexible masks
2014-10-22 09:01, Jingjing Wu: > add test command to configure flexible masks for each flow type [...] > --- a/app/test-pmd/cmdline.c > +++ b/app/test-pmd/cmdline.c > + "flow_director_flex_mask (port_id)" > + " flow (ether|ip4|tcp4|udp4|sctp4|ip6|tcp6|udp6|sctp6)" > + " words_mask (words) (word_mask_list)\n" > + "Configure mask of flex payload.\n\n" Does it mean we cannot use it for PPP? or for IP over PPPoE? -- Thomas
[dpdk-dev] [PATCH v2 04/13] ethdev: support of multiple sizes of redirection table
2014-10-28 13:20, Zhang, Helin: > From: Richardson, Bruce > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon > > > 2014-10-28 00:33, Zhang, Helin: > > > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > > > > 2014-09-25 16:40, Helin Zhang: > > > > > > /* Definitions used for redirection table entry size */ > > > > > > -#define ETH_RSS_RETA_NUM_ENTRIES 128 > > > > > > -#define ETH_RSS_RETA_MAX_QUEUE 16 > > > > > > +#define ETH_RSS_RETA_SIZE_64 64 > > > > > > +#define ETH_RSS_RETA_SIZE_128 128 > > > > > > +#define ETH_RSS_RETA_SIZE_512 512 > > > > > > + > > > > > > +#define RTE_BIT_WIDTH_64 (CHAR_BIT * sizeof(uint64_t)) > > > > > > > > > > Are these constants really needed? > > > > > > > > These constants were defined for the third input parameter of > > > > rte_eth_dev_rss_reta_update() and rte_eth_dev_rss_reta_query(). End > > > > users need > > > > to give the correct reta size listed as above, as other values is > > > > not valid. So it would be > > > > better to list the valid reta sizes in macros here. > > > > > If only limited range of values are allowed, would an enum work better than > > a set > > of macros? > > Good idea! Any other comments for this from other guys? I would prefer the API to be independent of the hardware capabilities. -- Thomas
[dpdk-dev] [PATCH v2] virtio: Update max RX packet length
Currently I have an issue in a pass-thorugh mode. I am running in multi process (2 processes) via ixgbe_rxtx. When running with a single process I have a perfect traffic while with 2 processes I have no traffic at all. Perhaps there is a special configuration for that, can you please assist ? Thanks Yan -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ouyang Changchun Sent: Monday, October 13, 2014 6:46 AM To: dev at dpdk.org Subject: [dpdk-dev] [PATCH v2] virtio: Update max RX packet length Update max RX packet length since virtio PMD has the capability of receiving and transmitting jumbo frame. This following patch provides the above capability: [dpdk-dev,v3] virtio: Support mergeable buffer in virtio pmd Submitter Ouyang Changchun Date Aug. 14, 2014, 8:54 a.m. Message ID <1408006475-17606-1-git-send-email-changchun.ouyang at intel.com> Permalink http://dpdk.org/dev/patchwork/patch/159/ Signed-off-by: Changchun Ouyang Tested-by: Jingguo Fu --- lib/librte_pmd_virtio/virtio_ethdev.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/librte_pmd_virtio/virtio_ethdev.h b/lib/librte_pmd_virtio/virtio_ethdev.h index d2e1eed..1da3c62 100644 --- a/lib/librte_pmd_virtio/virtio_ethdev.h +++ b/lib/librte_pmd_virtio/virtio_ethdev.h @@ -53,7 +53,7 @@ #define VIRTIO_MAX_TX_QUEUES 128 #define VIRTIO_MAX_MAC_ADDRS 1 #define VIRTIO_MIN_RX_BUFSIZE 64 -#define VIRTIO_MAX_RX_PKTLEN 1518 +#define VIRTIO_MAX_RX_PKTLEN 9728 /* Features desired/implemented by this driver. */ #define VTNET_FEATURES \ -- 1.8.4.2
[dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
Hi Yong, Is there any progress with this patchset? Thanks -- Thomas 2014-10-22 07:07, Cao, Waterman: > Hi Yong, > > We verified your patch with VMWare ESXi 5.5 and found VMware L2fwd and > L3fwd cmd can't run. > But We use DPDK1.7_rc1 package to validate VMware regression, It works > fine. > . > 1.[Test Environment]: > - VMware ESXi 5.5; > - 2 VM > - FC20 on Host / FC20-64 on VM > - Crown Pass server (E2680 v2 ivy bridge ) > - Niantic 82599 > > 2. [Test Topology]: > Create 2VMs (Fedora 18, 64bit) . > We pass through one physical port(Niantic 82599) to each VM, and also > create one virtual device: vmxnet3 in each VM. > To connect with two VMs, we use one vswitch to connect two vmxnet3 > interface. > Then, PF1 and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2. > The traffic flow for l2fwd/l3fwd is as below:: > Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> Ixia. (traffic > generator) > > 3.[ Test Step]: > > tar dpdk1.8.rc1 ,compile and run; > > L2fwd: ./build/l2fwd -c f -n 4 -- -p 0x3 > L3fwd: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 -config "(0,0,1),(1,0,2)" > > 4.[Error log]: > > ---VMware L2fwd:--- > > EAL: :0b:00.0 not managed by UIO driver, skipping > EAL: PCI device :13:00.0 on NUMA socket -1 > EAL: probe driver: 8086:10fb rte_ixgbe_pmd > EAL: PCI memory mapped at 0x7f678ae6e000 > EAL: PCI memory mapped at 0x7f678af34000 > PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 17, SFP+: 5 > PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x10fb > EAL: PCI device :1b:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd > EAL: PCI memory mapped at 0x7f678af33000 > EAL: PCI memory mapped at 0x7f678af32000 > EAL: PCI memory mapped at 0x7f678af3 > Lcore 0: RX port 0 > Lcore 1: RX port 1 > Initializing port 0... PMD: ixgbe_dev_rx_queue_setup(): > sw_ring=0x7f670b0f5580 hw_ring=0x7f6789fe5280 dma_addr=0x373e5280 > PMD: ixgbe_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are > satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0. > PMD: ixgbe_dev_rx_queue_setup(): Vector rx enabled, please make sure RX burst > size no less than 32. > PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f670b0f3480 > hw_ring=0x7f671b820080 dma_addr=0x100020080 > PMD: ixgbe_dev_tx_queue_setup(): Using simple tx code path > PMD: ixgbe_dev_tx_queue_setup(): Vector tx enabled. > done: > Port 0, MAC address: 90:E2:BA:4A:33:78 > > Initializing port 1... EAL: Error - exiting with code: 1 > Cause: rte_eth_tx_queue_setup:err=-22, port=1 > > ---VMware L3fwd:--- > > EAL: TSC frequency is ~2793265 KHz > EAL: Master core 1 is ready (tid=9f49a880) > EAL: Core 2 is ready (tid=1d7f2700) > EAL: PCI device :0b:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd > EAL: :0b:00.0 not managed by UIO driver, skipping > EAL: PCI device :13:00.0 on NUMA socket -1 > EAL: probe driver: 8086:10fb rte_ixgbe_pmd > EAL: PCI memory mapped at 0x7f079f3e4000 > EAL: PCI memory mapped at 0x7f079f4aa000 > PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 17, SFP+: 5 > PMD: eth_ixgbe_dev_init(): port 0 vendorID=0x8086 deviceID=0x10fb > EAL: PCI device :1b:00.0 on NUMA socket -1 > EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd > EAL: PCI memory mapped at 0x7f079f4a9000 > EAL: PCI memory mapped at 0x7f079f4a8000 > EAL: PCI memory mapped at 0x7f079f4a6000 > Initializing port 0 ... Creating queues: nb_rxq=1 nb_txq=1... > Address:90:E2:BA:4A:33:78, Allocated mbuf pool on socket 0 > LPM: Adding route 0x01010100 / 24 (0) > LPM: Adding route 0x02010100 / 24 (1) > LPM: Adding route 0x03010100 / 24 (2) > LPM: Adding route 0x04010100 / 24 (3) > LPM: Adding route 0x05010100 / 24 (4) > LPM: Adding route 0x06010100 / 24 (5) > LPM: Adding route 0x07010100 / 24 (6) > LPM: Adding route 0x08010100 / 24 (7) > txq=0,0,0 PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f071f6f3c80 > hw_ring=0x7f079e5e5280 dma_addr=0x373e5280 > PMD: ixgbe_dev_tx_queue_setup(): Using simple tx code path > PMD: ixgbe_dev_tx_queue_setup(): Vector tx enabled. > > Initializing port 1 ... Creating queues: nb_rxq=1 nb_txq=1... > Address:00:0C:29:F0:90:41, txq=1,0,0 EAL: Error - exiting with code: 1 > Cause: rte_eth_tx_queue_setup: err=-22, port=1 > > > Can you help to recheck this patch with latest DPDK code? > > Regards > Waterman > > -Original Message- > >From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yong Wang > >Sent: Wednesday, October 22, 2014 6:10 AM > >To: Patel, Rashmin N; Stephen Hemminger > >Cc: dev at dpdk.org > >Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement > > > >Rashmin/Stephen, > > > >Since you have worked on vmxnet3 pmd drivers, I wonder if you can help > >review this set of patches. Any other reviews/test verifications are > >welcome of course. We have reviewed/tested all patches internally. > > > >Yong > > > >From: d
[dpdk-dev] [PATCH v2] virtio: Update max RX packet length
2014-10-28 14:38, Yan Freedland: > Currently I have an issue in a pass-thorugh mode. > I am running in multi process (2 processes) via ixgbe_rxtx. > When running with a single process I have a perfect traffic > while with 2 processes I have no traffic at all. > Perhaps there is a special configuration for that, can you please assist ? Excuse me, I don't understand the relation between your question and the patch below. If there is no relation, please open a new thread by clicking on "new mail" instead of "reply all". Maybe that some kind developers will help you but you'd have more chances by providing your command line and more debug details showing that you tried to debug it by yourself and you are not a lazy developer. Reminder: some interesting links about mailing practices are in this page: http://dpdk.org/ml > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun > Sent: Monday, October 13, 2014 6:46 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] virtio: Update max RX packet length > > Update max RX packet length since virtio PMD has the capability of receiving > and transmitting jumbo frame. > > This following patch provides the above capability: > [dpdk-dev,v3] virtio: Support mergeable buffer in virtio pmd > Submitter Ouyang Changchun > Date Aug. 14, 2014, 8:54 a.m. > Message ID <1408006475-17606-1-git-send-email-changchun.ouyang at intel.com> > Permalink http://dpdk.org/dev/patchwork/patch/159/ > > Signed-off-by: Changchun Ouyang > Tested-by: Jingguo Fu > > --- > lib/librte_pmd_virtio/virtio_ethdev.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_pmd_virtio/virtio_ethdev.h > b/lib/librte_pmd_virtio/virtio_ethdev.h > index d2e1eed..1da3c62 100644 > --- a/lib/librte_pmd_virtio/virtio_ethdev.h > +++ b/lib/librte_pmd_virtio/virtio_ethdev.h > @@ -53,7 +53,7 @@ > #define VIRTIO_MAX_TX_QUEUES 128 > #define VIRTIO_MAX_MAC_ADDRS 1 > #define VIRTIO_MIN_RX_BUFSIZE 64 > -#define VIRTIO_MAX_RX_PKTLEN 1518 > +#define VIRTIO_MAX_RX_PKTLEN 9728 > > /* Features desired/implemented by this driver. */ #define VTNET_FEATURES \ > -- > 1.8.4.2
[dpdk-dev] [PATCH] mk: link combined lib using CC
On Tue, Oct 28, 2014 at 11:45:28AM +, De Lara Guarch, Pablo wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez > > Monroy > > Sent: Thursday, October 23, 2014 4:36 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] [PATCH] mk: link combined lib using CC > > > > Building combined shared libs fails if we set EXTRA_CFLAGS=-O0. > > > > /usr/bin/ld: test: hidden symbol `mknod' in > > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > > /usr/bin/ld: final link failed: Bad value > > collect2: error: ld returned 1 exit status > > > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > > > Signed-off-by: Sergio Gonzalez Monroy > > > > Plus, should we include compilation errors in commits? > They are quite useful to identify the problem that > the patch is solving, but not sure if this should be shown in the git log. > I was wondering about it myself. I think it is useful info but maybe t is more appropiate to have it as a comment or cover letter just on the mailing list. I don't have a strong preference for including it, maybe someone else has an opinion about this? Thanks, Sergio > Thanks, > Pablo >
[dpdk-dev] [PATCH v4 00/10] VM Power Management
Hi Alan, Did you make any progress in Qemu/KVM community? We need to be sync'ed up with them to be sure we share the same goal. I want also to avoid using a solution which doesn't fit with their plan. Remember that we already had this problem with ivshmem which was planned to be dropped. Thanks -- Thomas 2014-10-16 15:21, Carew, Alan: > Hi Thomas, > > > > However with a DPDK solution it would be possible to re-use the message > > > bus > > > to pass information like device stats, application state, D-state requests > > > etc. to the host and allow for management layer(e.g. OpenStack) to make > > > informed decisions. > > > > I think that management informations should be transmitted in a management > > channel. Such solution should exist in OpenStack. > > Perhaps it does, but this solution is not exclusive to OpenStack and just a > potential use case. > > > > > > Also, the scope of adding power management to qemu/KVM would be huge; > > > while the easier path is not always the best and the problem of power > > > management in VMs is both a DPDK problem (given that librte_power only > > > worked on the host) and a general virtualization problem that would be > > > better solved by those with direct knowledge of Qemu/KVM architecture > > > and influence on the direction of the Qemu project. > > > > Being a huge effort is not an argument. > > I agree completely and was implied by what followed the conjunction. > > > Please check with Qemu community, they'll welcome it. > > > > > As it stands, the host backend is simply an example application that can > > > be replaced by a VMM or Orchestration layer, by using Virtio-Serial it has > > > obvious leanings to Qemu, but even this could be easily swapped out for > > > XenBus, IVSHMEM, IP etc. > > > > > > If power management is to be eventually supported by Hypervisors directly > > > then we could also enable to option to switch to that environment, > > > currently > > > the librte_power implementations (VM or Host) can be selected dynamically > > > (environment auto-detection) or explicitly via rte_power_set_env(), adding > > > an arbitrary number of environments is relatively easy. > > > > Yes, you are adding a new layer to workaround hypervisor lacks. And this > > layer > > will handle native support when it will exist. But if you implement native > > support now, we don't need this extra layer. > > Indeed, but we have a solution implemented now and yes it is a workaround, > that is until Hypervisors support such functionality. It is possible that > whatever solutions for power management present themselves in the future may > require workarounds also, us-vhost is an example of such a workaround > introduced to DPDK. > > > > > > I hope this helps to clarify the approach. > > > > Thanks for your explanation. > > Thanks for the feedback. > > > > > -- > > Thomas > > Alan.
[dpdk-dev] [PATCH] mk: link combined lib using CC
2014-10-28 14:51, Sergio Gonzalez Monroy: > On Tue, Oct 28, 2014 at 11:45:28AM +, De Lara Guarch, Pablo wrote: > > > Building combined shared libs fails if we set EXTRA_CFLAGS=-O0. > > > > > > /usr/bin/ld: test: hidden symbol `mknod' in > > > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > > > /usr/bin/ld: final link failed: Bad value > > > collect2: error: ld returned 1 exit status > > > > > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > > > > > Signed-off-by: Sergio Gonzalez Monroy > > intel.com> > > > > Plus, should we include compilation errors in commits? > > They are quite useful to identify the problem that > > the patch is solving, but not sure if this should be shown in the git log. > > > I was wondering about it myself. I think it is useful info but maybe t is more > appropiate to have it as a comment or cover letter just on the mailing list. > I don't have a strong preference for including it, maybe someone else has an > opinion about this? We are not limited in characters in the commit log. So every useful information (like error output) is more than welcome. The only thing which needs to be shorter than a twitter post, is the title. Because short and clear titles help to scroll commits. That said, don't put things which have no interest at all. Here I'd put only this: ld: test: hidden symbol `mknod' in /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO -- Thomas
[dpdk-dev] [PATCH] mk: link combined lib using CC
On Tue, Oct 28, 2014 at 04:33:18PM +0100, Thomas Monjalon wrote: > 2014-10-28 14:51, Sergio Gonzalez Monroy: > > On Tue, Oct 28, 2014 at 11:45:28AM +, De Lara Guarch, Pablo wrote: > > > > Building combined shared libs fails if we set EXTRA_CFLAGS=-O0. > > > > > > > > /usr/bin/ld: test: hidden symbol `mknod' in > > > > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > > > > /usr/bin/ld: final link failed: Bad value > > > > collect2: error: ld returned 1 exit status > > > > > > > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > > > > > > > Signed-off-by: Sergio Gonzalez Monroy > > > intel.com> > > > > > > Plus, should we include compilation errors in commits? > > > They are quite useful to identify the problem that > > > the patch is solving, but not sure if this should be shown in the git log. > > > > > I was wondering about it myself. I think it is useful info but maybe t is > > more > > appropiate to have it as a comment or cover letter just on the mailing list. > > I don't have a strong preference for including it, maybe someone else has an > > opinion about this? > > We are not limited in characters in the commit log. So every useful > information > (like error output) is more than welcome. > The only thing which needs to be shorter than a twitter post, is the title. > Because short and clear titles help to scroll commits. > > That said, don't put things which have no interest at all. Here I'd put only > this: > ld: test: hidden symbol `mknod' in > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > Thanks for the tips! I'll send a v2 with changes. Sergio > -- > Thomas
[dpdk-dev] [PATCH v2] mk: link combined shared lib using CC
If we set EXTRA_CFLAGS=-O0, build fails with following error: /usr/bin/ld: test: hidden symbol `mknod' in /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO Fix: link combined shared lib using CC if LINK_USING_CC is enabled. Signed-off-by: Sergio Gonzalez Monroy --- mk/rte.lib.mk | 1 - mk/rte.sharelib.mk | 12 +++- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk index d83e808..a6abd6d 100644 --- a/mk/rte.lib.mk +++ b/mk/rte.lib.mk @@ -63,7 +63,6 @@ ifeq ($(LINK_USING_CC),1) # Override the definition of LD here, since we're linking with CC LD := $(CC) LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs) -CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS)) endif O_TO_A = $(AR) crus $(LIB) $(OBJS-y) diff --git a/mk/rte.sharelib.mk b/mk/rte.sharelib.mk index c0a811a..1fac0ad 100644 --- a/mk/rte.sharelib.mk +++ b/mk/rte.sharelib.mk @@ -29,6 +29,8 @@ # (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE # OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +include $(RTE_SDK)/mk/internal/rte.build-pre.mk + # VPATH contains at least SRCDIR VPATH += $(SRCDIR) @@ -45,7 +47,15 @@ sharelib: $(LIB_ONE) FORCE OBJS = $(wildcard $(RTE_OUTPUT)/build/lib/*.o) -O_TO_S = $(LD) $(CPU_LDFLAGS) -shared $(OBJS) -o $(RTE_OUTPUT)/lib/$(LIB_ONE) +ifeq ($(LINK_USING_CC),1) +# Override the definition of LD here, since we're linking with CC +LD := $(CC) $(CPU_CFLAGS) +LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs) +CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS)) +endif + +O_TO_S = $(LD) $(CPU_LDFLAGS) $(LD_MULDEFS) -shared $(OBJS)\ + -o $(RTE_OUTPUT)/lib/$(LIB_ONE) O_TO_S_STR = $(subst ','\'',$(O_TO_S)) #'# fix syntax highlight O_TO_S_DISP = $(if $(V),"$(O_TO_S_STR)"," LD $(@)") O_TO_S_CMD = "cmd_$@ = $(O_TO_S_STR)" -- 1.9.3
[dpdk-dev] [PATCH v2] mk: link combined shared lib using CC
> -Original Message- > From: Gonzalez Monroy, Sergio > Sent: Tuesday, October 28, 2014 3:49 PM > To: dev at dpdk.org > Cc: thomas.monjalon at 6wind.com; De Lara Guarch, Pablo > Subject: [PATCH v2] mk: link combined shared lib using CC > > If we set EXTRA_CFLAGS=-O0, build fails with following error: > > /usr/bin/ld: test: hidden symbol `mknod' in > /usr/lib64/libc_nonshared.a(mknod.oS) is referenced by DSO > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > Signed-off-by: Sergio Gonzalez Monroy > Acked-by: Pablo de Lara
[dpdk-dev] [PATCH v2] virtio: Update max RX packet length
Hi, I mistakenly pressed on reply all instead of reply and sent my question to the whole dev. Sorry about that. In fact I am not lazy and looks like I solved the problem by myself. I will gladly share my knowledge with you or anyone in dev and of course open a new mail thread with an appropriate subject for further appeals. Thank you, Yan -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: Tuesday, October 28, 2014 4:49 PM To: Yan Freedland Cc: dev at dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] virtio: Update max RX packet length 2014-10-28 14:38, Yan Freedland: > Currently I have an issue in a pass-thorugh mode. > I am running in multi process (2 processes) via ixgbe_rxtx. > When running with a single process I have a perfect traffic while with > 2 processes I have no traffic at all. > Perhaps there is a special configuration for that, can you please assist ? Excuse me, I don't understand the relation between your question and the patch below. If there is no relation, please open a new thread by clicking on "new mail" instead of "reply all". Maybe that some kind developers will help you but you'd have more chances by providing your command line and more debug details showing that you tried to debug it by yourself and you are not a lazy developer. Reminder: some interesting links about mailing practices are in this page: http://dpdk.org/ml > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ouyang Changchun > Sent: Monday, October 13, 2014 6:46 AM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2] virtio: Update max RX packet length > > Update max RX packet length since virtio PMD has the capability of receiving > and transmitting jumbo frame. > > This following patch provides the above capability: > [dpdk-dev,v3] virtio: Support mergeable buffer in virtio pmd > Submitter Ouyang Changchun > Date Aug. 14, 2014, 8:54 a.m. > Message ID <1408006475-17606-1-git-send-email-changchun.ouyang at intel.com> > Permalink http://dpdk.org/dev/patchwork/patch/159/ > > Signed-off-by: Changchun Ouyang > Tested-by: Jingguo Fu > > --- > lib/librte_pmd_virtio/virtio_ethdev.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/librte_pmd_virtio/virtio_ethdev.h > b/lib/librte_pmd_virtio/virtio_ethdev.h > index d2e1eed..1da3c62 100644 > --- a/lib/librte_pmd_virtio/virtio_ethdev.h > +++ b/lib/librte_pmd_virtio/virtio_ethdev.h > @@ -53,7 +53,7 @@ > #define VIRTIO_MAX_TX_QUEUES 128 > #define VIRTIO_MAX_MAC_ADDRS 1 > #define VIRTIO_MIN_RX_BUFSIZE 64 > -#define VIRTIO_MAX_RX_PKTLEN 1518 > +#define VIRTIO_MAX_RX_PKTLEN 9728 > > /* Features desired/implemented by this driver. */ #define > VTNET_FEATURES \ > -- > 1.8.4.2
[dpdk-dev] [PATCH] mk: fix build 32bits shared libs on 64bits system
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez > Monroy > Sent: Wednesday, October 22, 2014 5:36 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] mk: fix build 32bits shared libs on 64bits system > > Incompatible libraries error when building shared libraries for 32bits on > a 64bits system. > Fix issue by passing CPU_CFLAGS to CC when LINK_USING_CC is enabled. > > Signed-off-by: Sergio Gonzalez Monroy > Acked-by: Pablo de Lara
[dpdk-dev] [PATCH] mk: fix app linking for combined libs
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez > Monroy > Sent: Thursday, October 23, 2014 4:37 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH] mk: fix app linking for combined libs > > Building combined shared libraries results in applications being linked > against separeted/individual and combined libs altogether. Minor typo in the commit message: "separeted". > > Link only against combined lib when the config option is enabled. > > Signed-off-by: Sergio Gonzalez Monroy > Acked-by: Pablo de Lara
[dpdk-dev] VIRTIO indication
Hi In my multi process system I need to support 2 modes of work: pass through and VIRTIO. I saw that in order to work in a VIRTIO mode I need to update the txq_flags (part of the rte_eth_txconf structure) as follows: .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS | ETH_TXQ_FLAGS_NOOFFLOADS In pass - through however, this parameter should remain 0 (default value). Apparently I need to update this parameter in runtime. Is there any flag that can give me any indication on a mode I am running in. Thank you, Yan
[dpdk-dev] VIRTIO indication
Each device can tell you the driver name its bound to . This is enough to have separate configuration paths for vmxnet/virtio/ixgbe/etc... On Tue, Oct 28, 2014 at 7:21 PM, Yan Freedland wrote: > Hi > > In my multi process system I need to support 2 modes of work: pass through > and VIRTIO. > I saw that in order to work in a VIRTIO mode I need to update the > txq_flags (part of the rte_eth_txconf structure) as follows: > .txq_flags = ETH_TXQ_FLAGS_NOMULTSEGS | ETH_TXQ_FLAGS_NOOFFLOADS > > In pass - through however, this parameter should remain 0 (default value). > Apparently I need to update this parameter in runtime. Is there any flag > that can give me any indication on a mode I am running in. > > Thank you, > Yan > >
[dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
Thomas/Waterman,
I couldn't reproduce the reported issue on v1.8.0-rc1 and both l2fwd and l3fwd
works fine using the same command posted.
# dpdk_nic_bind.py --status
Network devices using DPDK-compatible driver
:0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
:13:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=
Network devices using kernel driver
===
:02:00.0 '82545EM Gigabit Ethernet Controller (Copper)' if=eth2 drv=e1000
unused=igb_uio *Active*
Other network devices
=
# ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 -config "(0,0,1),(1,0,2)"
...
EAL: TSC frequency is ~2800101 KHz
EAL: Master core 1 is ready (tid=ee3c6840)
EAL: Core 2 is ready (tid=de1ff700)
EAL: PCI device :02:00.0 on NUMA socket -1
EAL: probe driver: 8086:100f rte_em_pmd
EAL: :02:00.0 not managed by UIO driver, skipping
EAL: PCI device :0b:00.0 on NUMA socket -1
EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL: PCI memory mapped at 0x7f8bee3dd000
EAL: PCI memory mapped at 0x7f8bee3dc000
EAL: PCI memory mapped at 0x7f8bee3da000
EAL: PCI device :13:00.0 on NUMA socket -1
EAL: probe driver: 15ad:7b0 rte_vmxnet3_pmd
EAL: PCI memory mapped at 0x7f8bee3d9000
EAL: PCI memory mapped at 0x7f8bee3d8000
EAL: PCI memory mapped at 0x7f8bee3d6000
Initializing port 0 ... Creating queues: nb_rxq=1 nb_txq=1...
Address:00:0C:29:72:C6:7E, Allocated mbuf pool on socket 0
LPM: Adding route 0x01010100 / 24 (0)
LPM: Adding route 0x02010100 / 24 (1)
LPM: Adding route 0x03010100 / 24 (2)
LPM: Adding route 0x04010100 / 24 (3)
LPM: Adding route 0x05010100 / 24 (4)
LPM: Adding route 0x06010100 / 24 (5)
LPM: Adding route 0x07010100 / 24 (6)
LPM: Adding route 0x08010100 / 24 (7)
txq=0,0,0
Initializing port 1 ... Creating queues: nb_rxq=1 nb_txq=1...
Address:00:0C:29:72:C6:88, txq=1,0,0
Initializing rx queues on lcore 1 ... rxq=0,0,0
Initializing rx queues on lcore 2 ... rxq=1,0,0
done: Port 0
done: Port 1
L3FWD: entering main loop on lcore 2
L3FWD: -- lcoreid=2 portid=1 rxqueueid=0
L3FWD: entering main loop on lcore 1
L3FWD: -- lcoreid=1 portid=0 rxqueueid=0
I don't have the exact setup but I suspect this is related as the errors looks
like a tx queue param used is not supported by vmxnet3 backend. The patchset
does not touch the txq config path so it's not clear how it breaks
rte_eth_tx_queue_setup(). So my question to Waterman:
(1) Is this a regression on the same branch, i.e. running the unpatched build
works but failed with the patch applied?
(2) By any chance did you change the following struct in main.c for those
sample programs to a different value, in particular txq_flags?
static const struct rte_eth_txconf tx_conf = {
.tx_thresh = {
.pthresh = TX_PTHRESH,
.hthresh = TX_HTHRESH,
.wthresh = TX_WTHRESH,
},
.tx_free_thresh = 0, /* Use PMD default values */
.tx_rs_thresh = 0, /* Use PMD default values */
.txq_flags = (ETH_TXQ_FLAGS_NOMULTSEGS | <== any changes here?
ETH_TXQ_FLAGS_NOVLANOFFL |
ETH_TXQ_FLAGS_NOXSUMSCTP |
ETH_TXQ_FLAGS_NOXSUMUDP |
ETH_TXQ_FLAGS_NOXSUMTCP)
};
Thanks,
Yong
From: Thomas Monjalon
Sent: Tuesday, October 28, 2014 7:40 AM
To: Yong Wang
Cc: dev at dpdk.org; Cao, Waterman
Subject: Re: [dpdk-dev] [PATCH 0/5] vmxnet3 pmd fixes/improvement
Hi Yong,
Is there any progress with this patchset?
Thanks
--
Thomas
2014-10-22 07:07, Cao, Waterman:
> Hi Yong,
>
> We verified your patch with VMWare ESXi 5.5 and found VMware L2fwd and
> L3fwd cmd can't run.
> But We use DPDK1.7_rc1 package to validate VMware regression, It works
> fine.
> .
> 1.[Test Environment]:
> - VMware ESXi 5.5;
> - 2 VM
> - FC20 on Host / FC20-64 on VM
> - Crown Pass server (E2680 v2 ivy bridge )
> - Niantic 82599
>
> 2. [Test Topology]:
> Create 2VMs (Fedora 18, 64bit) .
> We pass through one physical port(Niantic 82599) to each VM, and also
> create one virtual device: vmxnet3 in each VM.
> To connect with two VMs, we use one vswitch to connect two vmxnet3
> interface.
> Then, PF1 and vmxnet3A are in VM1; PF2 and vmxnet3B are in VM2.
> The traffic flow for l2fwd/l3fwd is as below::
> Ixia -> PF1 -> vmxnet3A -> vswitch -> vmxnet3B -> PF2 -> Ixia. (traffic
> generator)
>
> 3.[ Test Step]:
>
> tar dpdk1.8.rc1 ,compile and run;
>
> L2fwd: ./build/l2fwd -c f -n 4 -- -p 0x3
> L3fwd: ./build/l3fwd-vf -c 0x6 -n 4 -- -p 0x3 -config "(0,0,1),(1,0,2)"
>
> 4.[Error log]:
>
> ---VMware L2fwd:---
>
> EAL: :0b:00.0 not managed by UIO driver, skipping
> EAL: PCI device :13:00.0 on NUMA socket -1
> EAL: probe driver: 8086:10fb rte_ixgbe_pmd
> EAL: PCI memory mapped at 0x7f678ae6e000
> EAL: PCI memory mapped at 0x7f678af34000
> P
[dpdk-dev] [PATCH 1/5] vmxnet3: Fix VLAN Rx stripping
On 10/22/14, 6:39 AM, "Stephen Hemminger" wrote: >On Mon, 13 Oct 2014 18:42:18 + >Yong Wang wrote: > >> Are you referring to the patch as a whole or your comment is about the >>reset of vlan_tci on the "else" (no vlan tags stripped) path? I am not >>sure I get your comments here. This patch simply fixes a bug on the rx >>vlan stripping path (where valid vlan_tci stripped is overwritten >>unconditionally later on the rx path in the original vmxnet3 pmd >>driver). All the other pmd drivers are doing the same thing in terms of >>translating descriptor status to rte_mbuf flags for vlan stripping. > >I was thinking that there are many fields in a pktmbuf and rather than >individually >setting them (like tci). The code should call the common >rte_pktmbuf_reset before setting >the fields. That way when someone adds a field to mbuf they don't have >to chasing >through every driver that does it's own initialization. Currently rte_pktmbuf_reset() is used in rte_pktmbuf_alloc() but looks like most pmd drivers use rte_rxmbuf_alloc() to replenish rx buffers, which directly calls __rte_mbuf_raw_alloc () without calling rte_pktmbuf_reset(). How about we change that in a separate patch to all pmd drivers so that we can keep their behavior consistent?
[dpdk-dev] SEGMENTATION FAULT in kni example : kni_free_kni() call
Hi, im trying the kni example. When i hit ctrl-c in the terminal stopping
the example, the os signals with a segmentation fault.
The issue is in this block of code:
static int kni_free_kni(uint8_t port_id) {
uint8_t i;
struct kni_port_params **p = kni_port_params_array;
if (port_id >= RTE_MAX_ETHPORTS || !p[port_id])
return -1;
-- for (i = 0; i < p[i]->nb_kni; i++) {
-- rte_kni_release(p[i]->kni[i]);
-- p[i]->kni[i] = NULL;
}
rte_eth_dev_stop(port_id);
return 0;
}
The following change fix that issue:
static int kni_free_kni(uint8_t port_id) {
uint8_t i;
struct kni_port_params **p = kni_port_params_array;
if (port_id >= RTE_MAX_ETHPORTS || !p[port_id])
return -1;
++ for (i = 0; i < p[port_id]->nb_kni; i++) {
++ rte_kni_release(p[port_id]->kni[i]);
++ p[port_id]->kni[i] = NULL;
}
rte_eth_dev_stop(port_id);
return 0;
}
Sorry for the basic of my fix ... i dont know the correct style to report
this kind of issues... im just a user of the dpdk library ... but i meet
this bug ...
Regards.
Ariel Horacio Rodriguez.
[dpdk-dev] [PATCH] add free hugepage function
On Wed, Oct 29, 2014 at 03:27:58AM +, Qiu, Michael wrote:
> I just saw one return path with value '0', and no any other place
> return a negative value, so it is better to be designed as one
> non-return function,
>
> +void
> +rte_eal_hugepage_free(void)
> +{
> + struct hugepage_file *hugepg_tbl = g_hugepage_table.hugepg_tbl;
> + unsigned i;
> + unsigned nr_hugefiles = g_hugepage_table.nr_hugefiles;
> +
> + RTE_LOG(INFO, EAL, "unlink %u hugepage files\n", nr_hugefiles);
> +
> + for (i = 0; i < nr_hugefiles; i++) {
> + unlink(hugepg_tbl[i].filepath);
> + hugepg_tbl[i].orig_va = NULL;
> + }
> +}
> +
>
> Thanks,
> Michael
Actually, I don't think that's quite right.
http://linux.die.net/man/2/unlink
"On success, zero is returned. On error, -1 is returned, and errno is set
appropriately." So it should be returning an error, and logging a message for
a file it cannot unlink or people will be surprised with weird failures.
It also had some minor typos / English in the comments but we can fix that too.
Matthew.
