[dpdk-dev] Questions about ACL library
Hi I'm a newbie in DPDK and have some very basic & stupid questions about ACL library. It is hard for me to understand DFA ACL library, especially the transition table and wildness which is used in trie generation and sorting. Why they use a transition table(=node array) to traverse a trie instead of using a node directly? Is there any document or URL for the DPDK ACL library? I already read the programmer's guide, but I want to understand constructing ACL trie, transition table and traversal way not the usage of ACL library.
[dpdk-dev] Performance regression in DPDK 1.8/2.0
Hi, Pablo : > Could you tell me how you got the L1 cache miss ratio? Perf? perf stat -e L1-dcache-loads,L1-dcache-misses l2fwd ... > Could you provide more information on how you run the l2fwd app, > in order to try to reproduce the issue: > - L2fwd Command line ./build/l2fwd -c 3 -n 2 -- -p 3 -q 2 > - L2fwd initialization (to check memory/CPU/NICs) I unfortunately did not save the output, but I wrote down the important parts: 1.7.1: no output regarding rx/tx code paths as init debug wasn't enabled 1.8.0 and 2.0.0: simple tx code path, vector rx Hardware: CPU: Intel(R) Xeon(R) CPU E3-1230 v2 TurboBoost and HyperThreading disabled. Frequency fixed at 3.30 GHz via acpi_cpufreq. NIC: X540-T2 Memory: Dual Channel DDR3 1333 MHz, 4x 4GB > Did you change the l2fwd app between versions? L2fwd uses simple rx on 1.7.1, > whereas it uses vector rx on 2.0 (enable IXGBE_DEBUG_INIT to check it). Yes, I had to update l2fwd when going from 1.7.1 to 1.8.0. However, the changes in the app were minimal. 1.8.0 and 2.0.0 used vector rx. Disabling vector rx via DPDK .config file causes another 30% performance loss so I kept it enabled. > Which packet format/size did you use? Does your traffic generator take into > account the Inter-packet gap? 64 Byte packets, full line rate on both ports, i.e. 14.88 Mpps per port. The packet's content doesn't matter as l2fwd doesn't look at it, but it was just some random stuff: EthType 0x1234. Let me know if you need any additional information. I'd also be interested in the configuration that resulted in the 20% speed- up that was mentioned in the original mbuf patch Paul
[dpdk-dev] data copy in vhost-user
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss > Sent: Tuesday, April 28, 2015 12:27 AM > To: Nikita Kalyazin; dev at dpdk.org > Subject: Re: [dpdk-dev] data copy in vhost-user > > > > On 27/04/15 12:54, Nikita Kalyazin wrote: > > Hi, > > > > > > As far as I understand, DPDK vhost-user implementation requires data copy > for either RX or TX (rte_vhost_dequeue_burst() and > rte_vhost_enqueue_burst()). It means that two data copies are needed to > transfer a packet from one VM to another. > > > > Why is not it possible to eliminate one of the copies (e.g., > rte_vhost_enqueue_burst() might set up a reference at vring descriptor to > mbuf's data rather than copying the data)? This had been added to the to-do list. We could delay the copy until the real copy is needed. > > I'm just guessing, but in case of VM-to-VM traffic the receiving one > could hold onto the buffer indefinitely, preventing the sender to reuse > the buffer. That could lead to a DoS in some cases, and shutting down > the sender would be also tricky. At least in case of Xen > netback/netfront that's the reason. A reasonable solution for this > problem is to make sure the buffer is swapped out with a copy after a > finite time. Do you mean we associate a timeout for the buffer? > > Regards, > > Zoltan
[dpdk-dev] [PATCH 03/18] i40e: adjustment of register definitions and relevant
Hi Thomas New version is needed, as previous version has some code piece which shouldn't be present there. > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 28, 2015 1:17 AM > To: Zhang, Helin > Cc: dev at dpdk.org; Kenguva, Monica; Murray, Steven J; Shih, Chiu-Pi > Subject: Re: [dpdk-dev] [PATCH 03/18] i40e: adjustment of register definitions > and relevant > > 2015-04-20 16:22, Helin Zhang: > > More register definitions and their relevant masks are added > > publically. Also few useless macros are deleted. > > > > Signed-off-by: Helin Zhang > > --- > > lib/librte_pmd_i40e/i40e/i40e_register.h | 1981 > > +- > > All these values are not used in the driver, right? Driver read/write some of registers defined in this header file. All registers and their relevant can be used by drivers, as these registers are treated as public registers. Of cause there are registers which is for internal use only. > > > --- a/lib/librte_pmd_i40e/i40e_ethdev.c > > +++ b/lib/librte_pmd_i40e/i40e_ethdev.c > > @@ -1269,9 +1269,6 @@ i40e_dev_stats_get(struct rte_eth_dev *dev, > struct rte_eth_stats *stats) > > I40E_GLPRT_BPTCL(hw->port), > > pf->offset_loaded, &os->eth.tx_broadcast, > > &ns->eth.tx_broadcast); > > - i40e_stat_update_32(hw, I40E_GLPRT_TDPC(hw->port), > > - pf->offset_loaded, &os->eth.tx_discards, > > - &ns->eth.tx_discards); > > The relation between this deletion and the rest of the patch is weird. All the registers defined in i40e_registers.h are public, though may not already been used in driver. It is not so weird that one of the deleted registers was being used in driver. Regards, Helin
[dpdk-dev] [PATCH 11/18] i40e: support of building both PF and VF driver together
Hi Thomas
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Tuesday, April 28, 2015 1:25 AM
> To: Zhang, Helin
> Cc: dev at dpdk.org; Kenguva, Monica; Murray, Steven J; Shih, Chiu-Pi
> Subject: Re: [dpdk-dev] [PATCH 11/18] i40e: support of building both PF and VF
> driver together
>
> 2015-04-20 16:22, Helin Zhang:
> > Macros of PF_DRIVER, VF_DRIVER and INTEGRATED_VF were defined to
> > support building both PF and VF driver together. PF_DRIVER needs to be
> > defined if a build is for PF only, while VF_DRIVER for VF only.
> > PF_DRIVER, VF_DRIVER and INTEGRATED_VF are all needed for building PF
> > and VF driver together.
> >
> > Signed-off-by: Helin Zhang
>
> As this patch is mostly reversing the logic #?fndef to #ifdef, it seems the
> title is
> not accurate. Is it really adding a new support or is it only changing the
> compilation logic?
It does have VF_DRIVER only before. Currently it will have both PF_DRIVER and
VF_DRIVER
which is used to select the source code to be compiled for PF or VF or both.
Yes, I need to think more accurate description.
>
> About title, please use i40e/base: to distinguish patches on the base driver
> from the specific PMD ones.
So i40e and i40e/base should be used respectively?
Regards,
Helin
>
> > ---
> > lib/librte_pmd_i40e/Makefile | 2 +-
> > lib/librte_pmd_i40e/i40e/i40e_adminq.c| 14 +++---
> > lib/librte_pmd_i40e/i40e/i40e_common.c| 6 --
> > lib/librte_pmd_i40e/i40e/i40e_prototype.h | 4 ++--
> > 4 files changed, 14 insertions(+), 12 deletions(-)
> >
> > diff --git a/lib/librte_pmd_i40e/Makefile
> > b/lib/librte_pmd_i40e/Makefile index a921bf1..22f0716 100644
> > --- a/lib/librte_pmd_i40e/Makefile
> > +++ b/lib/librte_pmd_i40e/Makefile
> > @@ -37,7 +37,7 @@ include $(RTE_SDK)/mk/rte.vars.mk LIB =
> > librte_pmd_i40e.a
> >
> > CFLAGS += -O3
> > -CFLAGS += $(WERROR_FLAGS)
> > +CFLAGS += $(WERROR_FLAGS) -DPF_DRIVER -DVF_DRIVER
> -DINTEGRATED_VF
> >
> > EXPORT_MAP := rte_pmd_i40e_version.map
> >
> > diff --git a/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> > b/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> > index 91b3568..8f9e870 100644
> > --- a/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> > +++ b/lib/librte_pmd_i40e/i40e/i40e_adminq.c
> > @@ -37,7 +37,7 @@ POSSIBILITY OF SUCH DAMAGE.
> > #include "i40e_adminq.h"
> > #include "i40e_prototype.h"
> >
> > -#ifndef VF_DRIVER
> > +#ifdef PF_DRIVER
> > /**
> > * i40e_is_nvm_update_op - return true if this is an NVM update operation
> > * @desc: API request descriptor
> > @@ -48,7 +48,7 @@ STATIC INLINE bool i40e_is_nvm_update_op(struct
> i40e_aq_desc *desc)
> > desc->opcode == CPU_TO_LE16(i40e_aqc_opc_nvm_update));
> > }
> >
> > -#endif /* VF_DRIVER */
> > +#endif /* PF_DRIVER */
> > /**
> > * i40e_adminq_init_regs - Initialize AdminQ registers
> > * @hw: pointer to the hardware structure @@ -559,7 +559,7 @@
> enum
> > i40e_status_code i40e_shutdown_arq(struct i40e_hw *hw) enum
> > i40e_status_code i40e_init_adminq(struct i40e_hw *hw) {
> > enum i40e_status_code ret_code;
> > -#ifndef VF_DRIVER
> > +#ifdef PF_DRIVER
> > u16 eetrack_lo, eetrack_hi;
> > int retry = 0;
> > #endif
> > @@ -592,7 +592,7 @@ enum i40e_status_code i40e_init_adminq(struct
> i40e_hw *hw)
> > if (ret_code != I40E_SUCCESS)
> > goto init_adminq_free_asq;
> >
> > -#ifndef VF_DRIVER
> > +#ifdef PF_DRIVER
> > #ifdef INTEGRATED_VF
> > /* VF has no need of firmware */
> > if (i40e_is_vf(hw))
> > @@ -640,13 +640,13 @@ enum i40e_status_code i40e_init_adminq(struct
> i40e_hw *hw)
> > I40E_HMC_PROFILE_DEFAULT,
> > 0,
> > NULL);
> > +#endif /* PF_DRIVER */
> > ret_code = I40E_SUCCESS;
> >
> > -#endif /* VF_DRIVER */
> > /* success! */
> > goto init_adminq_exit;
> >
> > -#ifndef VF_DRIVER
> > +#ifdef PF_DRIVER
> > init_adminq_free_arq:
> > i40e_shutdown_arq(hw);
> > #endif
> > @@ -1044,7 +1044,7 @@ clean_arq_element_out:
> > *pending = (ntc > ntu ? hw->aq.arq.count : 0) + (ntu - ntc);
> > i40e_release_spinlock(&hw->aq.arq_spinlock);
> >
> > -#ifndef VF_DRIVER
> > +#ifdef PF_DRIVER
> > if (i40e_is_nvm_update_op(&e->desc)) {
> > if (hw->aq.nvm_release_on_done) {
> > i40e_release_nvm(hw);
> > diff --git a/lib/librte_pmd_i40e/i40e/i40e_common.c
> > b/lib/librte_pmd_i40e/i40e/i40e_common.c
> > index 3dd8f04..7a322f1 100644
> > --- a/lib/librte_pmd_i40e/i40e/i40e_common.c
> > +++ b/lib/librte_pmd_i40e/i40e/i40e_common.c
> > @@ -44,7 +44,7 @@ POSSIBILITY OF SUCH DAMAGE.
> > * This function sets the mac type of the adapter based on the
> > * vendor ID and device ID stored in the hw structure.
> > **/
> > -#ifdef VF_DRIVER
> > +#if defined(INTEGRATED_VF) || defined(VF_DRIVER)
> > enum i40e_status_code i40e_
[dpdk-dev] [PATCH 12/18] i40e: enhancements of AQ commands and common interfaces
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 28, 2015 1:27 AM > To: Zhang, Helin > Cc: dev at dpdk.org; Kenguva, Monica; Murray, Steven J; Shih, Chiu-Pi > Subject: Re: [dpdk-dev] [PATCH 12/18] i40e: enhancements of AQ commands > and common interfaces > > 2015-04-20 16:22, Helin Zhang: > > 'LE16_TO_CPU' was added in 'i40e_debug_aq()' to support big-endian and > > little endian correctly. Fix of determing the PF number was added for > > 'i40e_init_shared_code()', which can solve the issue of PF > > pass-through. Also enhancements were added for 'i40e_led_get()' > > and 'i40e_led_set()'. 'i40e_update_link_info()' was removed and > > replaced by 'i40e_aq_get_link_info()' directly. > > 'i40e_aq_debug_read_register()' was added for reading internal > > registers for debug purpose. > > It seems there are really several patches in one. > Please split to allow good tracking. Yes, agree. Regards, Helin
[dpdk-dev] [PATCH 13/18] i40e: replacement of 'i40e_debug_read_register()'
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 28, 2015 1:29 AM > To: Zhang, Helin > Cc: dev at dpdk.org; Kenguva, Monica; Murray, Steven J; Shih, Chiu-Pi > Subject: Re: [dpdk-dev] [PATCH 13/18] i40e: replacement of > 'i40e_debug_read_register()' > > 2015-04-20 16:22, Helin Zhang: > > As base driver provides 'i40e_aq_debug_read_register()', the same > > functional interface of 'i40e_debug_read_register()' can be replaced. > > > > Signed-off-by: Helin Zhang > > --- > > lib/librte_pmd_i40e/i40e_ethdev.c | 22 ++ > > 1 file changed, 2 insertions(+), 20 deletions(-) > > It should be merged with the patch introducing the function in the base > driver. > So it will be easier to check what changed. OK. Agree with you! Regards, Helin
[dpdk-dev] [PATCH RFC 00/10] Add a VXLAN sample
Hi All, So far, I have not got any comments yet, which means all of you agree on the proposal of the VXLAN example? Actually, if I can get your comments as soon as possible, which can avoid a lot of discussions in formal patch set and can accelerate the development. Thanks Jijiang Liu > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jijiang Liu > Sent: Thursday, April 16, 2015 11:56 AM > To: dev at dpdk.org; Gilmore, Walter E; Long, Thomas > Subject: [dpdk-dev] [PATCH RFC 00/10] Add a VXLAN sample > > This VXLAN example simulates a VXLAN Tunnel endpoint(VTEP) termination in > DPDK, which is used to demonstrate the offload and filtering capabilities of > i40 > NIC for VXLAN packet. > > And this example uses the basic virtio devices management function from vHost > example, and it uses us-Vhost interface and tunnel filtering mechanism to > direct > the traffic to/from a specific VM. > > In addition, this sample is also designed to show how tunneling protocols can > be > handled. For the vHost interface, we do not need to support zero copy/inter VM > packet transfer etc. The approach that we take would be of benefit to you in > that we put a pluggable structure in place so that the application could be > easily > extended to support a new tunneling protocol. > > The software framework is as follows: > >|---| |---| >| VM-1(VNI:100) | | VM-2(VNI:200)| >| |--| |--| | | |--| |--| | >| |vport0| |vport1| | | |vport0| |vport1| | >|-|--|-|--|-| |-|--|-|--|-| Guests > \ / > |-\---/| > | us-vHost interface | > | |-||--| | > | decap| | TEP| | encap | DPDK App > | |-||--| | > |||| > |||| > || > |-||---| > |tunnel filter|| IP/L4 Tx csum | > |IP/L4 csum || TSO | > |packet type || | NIC > |CRC strip|| | > |-||---| > || > || > || > /---\ > VXLAN Tunnel > > The sample will support the followings: > 1> Tunneling packet recognition. > > 2> The port of UDP tunneling is configurable > > 3> Directing of incoming traffic to the correct queue based on the tunnel > filter > type such as inner MAC address and VNI. > The VNI will be assigned from a static internal table based on the us- > vhost device ID. Each device will receive a unique device ID. The inner MAC > will > be learned from the first packet transmitted from a device. > > 4> Decapsulation of Rx VXLAN traffic. This is a software only > 4> operation(will use HW header split instead later) > > 5> Encapsulation of Tx VXLAN traffic. This is a software only operation > > 6> Tx outer IP, inner IP and L4 checksum offload > > 7> TSO support for tunneling packet > > Limitations: > 1. No ARP support > 2. There are some duplicated source codes because of using the basic virtio > device management function from vhost sample, but consider that current vhost > sample is quite complicated and huge enough, and I think we shall have a > separate sample for tunneling packet processing. > 3. Currently, only the i40e NIC is supported in the sample, but other types of > NICs also can be supported later if those NICs are able to support tunneling > packet filter. > > > Jijiang Liu (10): > create VXLAN sample framework using virtio device management function > add basic VXLAN structures > add VXLAN operation APIs > support overlay operations > Add encapsulation and decapsulation function > add udp port configuration > add filter type configuration > add tx checksum offload configuration > add TSO offload configuration > add encapsulation and decapsulation flags > > examples/Makefile |1 + > examples/tep_termination/Makefile | 58 ++ > examples/tep_termination/main.c| 1117 > > examples/tep_termination/main.h| 113 > examples/tep_termination/vxlan.c | 242 +++ > examples/tep_termination/vxlan.h | 81 +++ > examples/tep_termination/vxlan_setup.c | 453 + > examples/tep_termination/vxlan_setup.h | 76 +++ > 8 files changed, 2141 insertions(+), 0 deletions(-) create mode 100644 > examples/tep_termination/Makefile create mode 100644 > examples/tep_termination/main.c create mode 100644 > examples/tep_termination/main.h create mode 100644 > examples/tep_
[dpdk-dev] Beyond DPDK 2.0
On Mon, Apr 27, 2015 at 5:29 AM, Jim Thompson wrote: > > > On Apr 26, 2015, at 4:56 PM, Neil Horman wrote: > > > > On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote: > >> +1 and besides the GPL or LGPL ship has sailed IMHO and we can not go > back. > > Actually, IANAL, but I think we can. The BSD license allows us to fork > and > > relicense the code I think, under GPL or any other license. I'm not > advocating > > for that mind you, just suggesting that its possible should it ever > become > > needed. > > I, on the other hand, am fairly certain that you can not ?relicense BSD > licensed code under the GPL (or any other license). > > Were this true at law, then the opposite would also be possible. (?Don?t > like the license? Just fork!?) > > +1 While BSD carries many benefits for DPDK (similar to any other library), GPL doesn't carry any benefit in this case. It's not wise not to contribute back to DPDK regardless of any license of choice. Those who do not wish to contribute will always manage to do.. Going back to the list of open source projects on top of DPDK I like to mention the SeaStar project: http://www.seastar-project.org For those who aren't familiar, SeaStar is a high speed messaging framework with a unique shared-nothing approach with a per-core granularity. For our knowledge it offers the first open source TCP/IP implementation on top of DPDK along with many other advantages. DPDK is one of the main building blocks that allow us to reach millions of iops and we're pretty pleased with the project - both the source code as well as the community! Dor
[dpdk-dev] What to do about UIO breakage in 2.0
On 4/28/2015 6:06 AM, Stephen Hemminger wrote: > I raised the issue, but people seem to be ignoring that fact that igb_uio > was broken by the introduction of UIO PCI generic in 2.0. What do you mean about igb_uio broken? Thanks, Michael > > There are three options: > 1. Remove IGB_UIO only use UIO PCI generic. > Downside there is no MSI-X support for UIO PCI generic. > 2. Revert UIO PCI generic support > 3. Replace both of the above with something better. > > I am working on #3 but it will not be ready for 2.0.1 and there > is no solution for users of 2.0 and any future stable code. >
[dpdk-dev] [PATCH v6 03/13] mbuf: add accessors to get data room size and private size
2015-04-22 11:57, Olivier Matz:
> This code retrieving the pool private area is duplicated in many
> places, we can use of function for it.
>
> Signed-off-by: Olivier Matz
> Acked-by: Neil Horman
[...]
> --- a/lib/librte_pmd_pcap/rte_eth_pcap.c
> +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c
> @@ -136,9 +136,7 @@ eth_pcap_rx(void *queue,
> const u_char *packet;
> struct rte_mbuf *mbuf;
> struct pcap_rx_queue *pcap_q = queue;
> - struct rte_pktmbuf_pool_private *mbp_priv;
> uint16_t num_rx = 0;
> - uint16_t buf_size;
>
> if (unlikely(pcap_q->pcap == NULL || nb_pkts == 0))
> return 0;
> @@ -157,8 +155,7 @@ eth_pcap_rx(void *queue,
> break;
>
> /* Now get the space available for data in the mbuf */
> - mbp_priv = rte_mempool_get_priv(pcap_q->mb_pool);
> - buf_size = (uint16_t) (mbp_priv->mbuf_data_room_size -
> + buf_size =
> (uint16_t)(rte_pktmbuf_data_room_size(pcap_q->mb_pool) -
> RTE_PKTMBUF_HEADROOM);
>
> if (header.len <= buf_size) {
It doesn't compile because buf_size is removed by error:
lib/librte_pmd_pcap/rte_eth_pcap.c: In function ?eth_pcap_rx?:
lib/librte_pmd_pcap/rte_eth_pcap.c:158:3: error: ?buf_size? undeclared (first
use in this function)
I fix it while applying patches.
[dpdk-dev] i40e and RSS woes
Hi, I didn't follow DPDK development to close lately. Was those problem fixed already? On Thu, Mar 05, 2015 at 06:56:14AM +, Zhang, Helin wrote: > > > > -Original Message- > > From: Gleb Natapov [mailto:gleb at cloudius-systems.com] > > Sent: Thursday, March 5, 2015 2:39 PM > > To: Zhang, Helin > > Cc: dev at dpdk.org > > Subject: Re: i40e and RSS woes > > > > On Thu, Mar 05, 2015 at 05:56:27AM +, Zhang, Helin wrote: > > > Hi Gleb > > > > > > Sorry for late! I am struggling on my tasks for the following DPDK release > > these days. > > > > > > > -Original Message- > > > > From: Gleb Natapov [mailto:gleb at cloudius-systems.com] > > > > Sent: Monday, March 2, 2015 8:56 PM > > > > To: dev at dpdk.org > > > > Cc: Zhang, Helin > > > > Subject: Re: i40e and RSS woes > > > > > > > > Ping. > > > > > > > > On Thu, Feb 19, 2015 at 04:50:10PM +0200, Gleb Natapov wrote: > > > > > CCing i40e driver author in a hope to get an answer. > > > > > > > > > > On Mon, Feb 16, 2015 at 03:36:54PM +0200, Gleb Natapov wrote: > > > > > > I have an application that works reasonably well with ixgbe > > > > > > driver, but when I try to use it with i40e I encounter various RSS > > > > > > related > > issues. > > > > > > > > > > > > First one is that for some reason i40e, when it builds default > > > > > > reta table, round down number of queues to power of two. Why is > > > > > > this? If > > > It seems because of i40e queue configuration. We will check it more > > > and see if it can be changed or improved later. > > > > > Thanks, as I said below when I configure reta by myself everything work as > > expected - traffic is received on all queues, so I am curious if in some > > scenarios > > my code can break. > > > > > > > > I configure reta by my own using all of the queues everything > > > > > > seams to be working. To add insult to injury I do not get any > > > > > > errors during configuration some queues just do not receive any > > > > > > traffic. > > > > > > > > > > > > The second problem is that for some reason i40e does not use 40 > > > > > > byte toeplitz hash key like any other driver, but it expects the > > > > > > key to be 52 bytes. And it would have being fine (if we ignore > > > > > > the fact that it contradicts MS spec), but how my high level > > > > > > code suppose to know > > > > that? > > > Actually a rss_key_len was introduced in struct rte_eth_rss_conf > > > recently. So the length should be indicated clearly. But I found the > > > annotations of that structure should have been reworked. I will try to > > > rework > > it with clear descriptions. > > > > > I saw rss_key_len of course, my question is how my code suppose to know > > what value to set it to? Why required key length is not part of a device > > capability query (or is it and I missed it)? The only way I found to get > > key length > > is to quire device for a key, and check rss_key_len. If it is zero then key > > is 40 > > bytes, otherwise whatever rss_key_len says. This method is more of a hack > > then proper way to do it. > I think it was missed. I will add it soon later. > > > > > > > > > And again, device configuration does not fail when wrong key > > > > > > length is provided, it just uses some other key. Guys this kind > > > > > > of error handling is completely unacceptable. > > > If less length of key is provided, it will not be used at all, the > > > default key will be > > used. > > > So there is no issue as you said. But we need to add more clear > > > description for the structure of rte_eth_rss_conf. > > > > > What you've said above is exactly the issue! My code does not work if a key > > used by HW is not the same as was set by application, but since I get no > > error > > when my setting is ignored the is not way for me to know that my application > > will not work (short of querying key back and comparing which is again a > > hack). > > Device configuration should fail if it cannot apply my settings. > After I checked the code, different PMD may have different implementation. > Returning with an error might be the best way for all PMDs. I will unify it > later. > > Really good findings and suggestions from you! Thank you very much! > -- Gleb.
[dpdk-dev] [PATCH v6 00/13] mbuf: enhancements of mbuf clones
> > The first objective of this series is to fix the support of indirect > > mbufs when the application reserves a private area in mbufs. It also > > removes the limitation that rte_pktmbuf_clone() is only allowed on > > direct (non-cloned) mbufs. The series also contains some enhancements > > and fixes in the mbuf area that makes the implementation of the > > last patches easier. > > > > Changes in v6: > > - restore the priv_size in mbuf structure, version 4 broke the > > attachment between mbufs having different private size > > - add a test case to ensure it won't be broken again > > - replace 0x by UINT16_MAX > > - fix some minor checkpatch issues > > > > Changes in v5: > > - update rte_mbuf_version.map to fix compilation with shared libraries > > > > Changes in v4: > > - do not add a priv_size in mbuf structure, having a proper accessor > > to read it from the pool private area is clearer > > - prepend some reworks in the mbuf area to simplify the implementation > > (fix mbuf initialization by not using a hardcoded mbuf size, add > > accessors for mbuf pool private area, add a helper to create a > > mbuf pool) > > > > Changes in v3: > > - a mbuf can now attach to another one that have a different private > > size. In this case, the m->priv_size corresponds to the size of the > > private area of the direct mbuf. > > - add comments to reflect these changes > > - minor style modifications > > > > Changes in v2: > > - do not change the use of MBUF_EXT_MEM() in vhost > > - change rte_mbuf_from_baddr() to rte_mbuf_from_indirect(), removing > > one parameter > > - fix and rework rte_pktmbuf_detach() > > - move m->priv_size in second mbuf cache line > > - fix mbuf free in test error case > > > > Olivier Matz (13): > > mbuf: fix mbuf data room size calculation rte_pktmbuf_pool_init > > examples: always initialize mbuf_pool private area > > mbuf: add accessors to get data room size and private size > > mbuf: fix rte_pktmbuf_init when mbuf private size is not zero > > testpmd: use standard functions to initialize mbufs and mbuf pool > > mbuf: introduce a new helper to create a mbuf pool > > apps: use rte_pktmbuf_pool_create to create mbuf pools > > mbuf: fix clone support when application uses private mbuf data > > mbuf: allow to clone an indirect mbuf > > test/mbuf: rename mc variable in m > > test/mbuf: enhance mbuf refcnt test > > test/mbuf: verify that cloning a clone works properly > > test/mbuf: add a test case for clone with different priv size > > Acked-by: Konstantin Ananyev Applied, thanks
[dpdk-dev] [PATCH] ACL: use setjmp/longjmp to handle memory allocation failure at build phase
> During build phase ACL doing quite a lot of memory allocations > for relatively small temporary structures. > In theory each of such allocation can fail, so we need to handle > all these possible failures. > That adds a lot of extra checks and makes the code harder to read and follow. > To simplify the process, made changes to handle all such failures > in one place. > Note, that all that memory for temporary structures > is freed at one go at the end of build phase. > > Signed-off-by: Konstantin Ananyev Applied, thanks
[dpdk-dev] Can't allocate different number of TX and RX queues for single port of ixgbe NIC
Hello, Network Performance Gurus! I have Debian Jessie with 3.16 kernel, DPDK 2.0.0 with ixgbe NIC. And I wrote following code: https://gist.github.com/pavel-odintsov/e1f64de4d56c0ab1b37c I try to allocate 2 queues for TX and only 1 queue for RX and I can't do it with error (detailed error message https://gist.github.com/pavel-odintsov/507cf7a082793f547120): PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f9e9dcdbc80 hw_ring=0x7f9e9dd41500 dma_addr=0x36b41500 PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f9e9dcd9b40 hw_ring=0x7f9e9dd51580 dma_addr=0x36b51580 PMD: ixgbe_set_tx_function(): Using simple tx code path PMD: ixgbe_set_tx_function(): Vector tx enabled. EAL: Error - exiting with code: 1 Cause: Can't configure TX queue 1 for port 0 I could fix this issue with allocation 2 queues for TX and 2 queues for RX. But it's useless for my aplication because I need multiple TX queue but could use only one RX and I want ability to specify different number of queues for NIC. Thank you so much! -- Sincerely yours, Pavel Odintsov
[dpdk-dev] [PATCH 0/3] pcap pmd improvements
Please Nicolas, John, could we have a review of these patches? Thanks 2015-02-27 15:42, Tero Aho: > We have found it convenient to use pcap interfaces in early development > when speed does not matter. However, pcap interfaces use fixed values > for some properties like link status which makes it hard to simulate > certain conditions. > > Here's series of small improvements we have originally used on top > of v1.7.0 (now rebased to current master). > > Tero Aho (3): > pcap: utilize underlying real interface properties > pcap: add support for jumbo frames > pcap: add byte and error counters into statistics > > lib/librte_pmd_pcap/rte_eth_pcap.c | 176 > +++-- > 1 file changed, 151 insertions(+), 25 deletions(-)
[dpdk-dev] [PATCH] kni: fix igb and ixgbe kni ethtool get_link op
Helin, Do you have time to check this patch, please? 2015-04-03 23:18, Shelton Chia: > igb and ixgbe's link detected always return yes, fix get_link func > refer to get_settings, it works correctly for my i350 and 82599es nic. > > Signed-off-by: Shelton Chia
[dpdk-dev] Performance regression in DPDK 1.8/2.0
Hi, sorry, I mixed up the hardware I used for my tests. Paul Emmerich : > CPU: Intel(R) Xeon(R) CPU E3-1230 v2 > TurboBoost and HyperThreading disabled. > Frequency fixed at 3.30 GHz via acpi_cpufreq. The CPU frequency was fixed at 1.60 GHz to enforce a CPU bottleneck. My original post said that I used a Xeon E5-2620 v3 at 1.2 GHz, this is incorrect. The calculation for Cycles/Pkt in the original post used the correct 1.6 GHz figure, though. (I used the E5 CPU for the evaluation of my packet generator performance with 1.7.1/2.0.0, not for the l2fwd test.) Sorry for the confusion. Paul
[dpdk-dev] Performance regression in DPDK 1.8/2.0
On Tue, Apr 28, 2015 at 12:43:16PM +0200, Paul Emmerich wrote: > Hi, > > sorry, I mixed up the hardware I used for my tests. > > > Paul Emmerich : > > CPU: Intel(R) Xeon(R) CPU E3-1230 v2 > > TurboBoost and HyperThreading disabled. > > Frequency fixed at 3.30 GHz via acpi_cpufreq. > > The CPU frequency was fixed at 1.60 GHz to enforce > a CPU bottleneck. > > > My original post said that I used a Xeon E5-2620 v3 > at 1.2 GHz, this is incorrect. The calculation for Cycles/Pkt > in the original post used the correct 1.6 GHz figure, though. > > (I used the E5 CPU for the evaluation of my packet generator > performance with 1.7.1/2.0.0, not for the l2fwd test.) > > > Sorry for the confusion. > > > Paul Thanks for the update - we are investigating. /Bruce
[dpdk-dev] Performance regression in DPDK 1.8/2.0
Hi, Matthew Hall : > Not sure if it's relevant or not, but there was another mail claiming PCIe > MSI-X wasn't necessarily working in DPDK 2.x. Not sure if that could be > causing slowdowns when there are drastic volumes of 64-byte packets causing a > lot of PCI activity. Interrupts should not be relevant here. > Also, you are mentioning some specific patches were involved... so I have to > ask if anybody tried git bisect yet or not. Maybe easier than trying to guess > at the answer. I have not yet tried to bisect it, but that?s the next step on my todo list*. The mbuf patch was just an educated guess to start a discussion. I hoped that I was just doing something obvious wrong, and/or that someone could point me to performance regression tests that were executed to proof that the mbuf patch does not affect performance. However, there don?t seem to be any 'official? performance regression tests, are there? Paul * I probably won?t be able to it until next week, though as I have to to finish the paper about my packet generator
[dpdk-dev] Can't allocate different number of TX and RX queues for single port of ixgbe NIC
Hi Pavel, I think mistake is here: -int eth_configure_ret = rte_eth_dev_configure(current_port, tx_queues, rx_queues, &default_port_conf); +int eth_configure_ret = rte_eth_dev_configure(current_port, rx_queues, tx_queues, &default_port_conf); according to http://dpdk.org/doc/api/rte__ethdev_8h.html#ac30d075b4b206c7122e200164ce69893 second arg is number of rx queues Regards, Vladimir 2015-04-28 13:02 GMT+03:00 Pavel Odintsov : > Hello, Network Performance Gurus! > > I have Debian Jessie with 3.16 kernel, DPDK 2.0.0 with ixgbe NIC. And > I wrote following code: > https://gist.github.com/pavel-odintsov/e1f64de4d56c0ab1b37c > > I try to allocate 2 queues for TX and only 1 queue for RX and I can't > do it with error (detailed error message > https://gist.github.com/pavel-odintsov/507cf7a082793f547120): > PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f9e9dcdbc80 > hw_ring=0x7f9e9dd41500 dma_addr=0x36b41500 > PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f9e9dcd9b40 > hw_ring=0x7f9e9dd51580 dma_addr=0x36b51580 > PMD: ixgbe_set_tx_function(): Using simple tx code path > PMD: ixgbe_set_tx_function(): Vector tx enabled. > EAL: Error - exiting with code: 1 > Cause: Can't configure TX queue 1 for port 0 > > I could fix this issue with allocation 2 queues for TX and 2 queues > for RX. But it's useless for my aplication because I need multiple TX > queue but could use only one RX and I want ability to specify > different number of queues for NIC. > > Thank you so much! > > -- > Sincerely yours, Pavel Odintsov >
[dpdk-dev] Performance regression in DPDK 1.8/2.0
On Tue, Apr 28, 2015 at 12:28:34AM +0200, Paul Emmerich wrote: > Let me know if you need any additional information. > I'd also be interested in the configuration that resulted in the 20% speed- > up that was mentioned in the original mbuf patch > > Paul > The speed-up would be for apps that were doing RX of scattered packets, i.e. across mbufs. Before 1.8, this was using a scalar function which was rather slow compared to the fast-path vector function. In 1.8 we introduced a new vector function which supported scattered packets - it still isn't as fast as the non-scattered packet RX function, but it was a good improvement over the older version. /Bruce
[dpdk-dev] Can't allocate different number of TX and RX queues for single port of ixgbe NIC
Wow! Thank you so much :) It works fine now! On Tue, Apr 28, 2015 at 1:57 PM, Vladimir Medvedkin wrote: > Hi Pavel, > > I think mistake is here: > -int eth_configure_ret = rte_eth_dev_configure(current_port, tx_queues, > rx_queues, &default_port_conf); > +int eth_configure_ret = rte_eth_dev_configure(current_port, rx_queues, > tx_queues, &default_port_conf); > according to > http://dpdk.org/doc/api/rte__ethdev_8h.html#ac30d075b4b206c7122e200164ce69893 > second arg is number of rx queues > > Regards, > Vladimir > > 2015-04-28 13:02 GMT+03:00 Pavel Odintsov : >> >> Hello, Network Performance Gurus! >> >> I have Debian Jessie with 3.16 kernel, DPDK 2.0.0 with ixgbe NIC. And >> I wrote following code: >> https://gist.github.com/pavel-odintsov/e1f64de4d56c0ab1b37c >> >> I try to allocate 2 queues for TX and only 1 queue for RX and I can't >> do it with error (detailed error message >> https://gist.github.com/pavel-odintsov/507cf7a082793f547120): >> PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7f9e9dcdbc80 >> hw_ring=0x7f9e9dd41500 dma_addr=0x36b41500 >> PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7f9e9dcd9b40 >> hw_ring=0x7f9e9dd51580 dma_addr=0x36b51580 >> PMD: ixgbe_set_tx_function(): Using simple tx code path >> PMD: ixgbe_set_tx_function(): Vector tx enabled. >> EAL: Error - exiting with code: 1 >> Cause: Can't configure TX queue 1 for port 0 >> >> I could fix this issue with allocation 2 queues for TX and 2 queues >> for RX. But it's useless for my aplication because I need multiple TX >> queue but could use only one RX and I want ability to specify >> different number of queues for NIC. >> >> Thank you so much! >> >> -- >> Sincerely yours, Pavel Odintsov > > -- Sincerely yours, Pavel Odintsov
[dpdk-dev] [PATCH v6 00/13] mbuf: enhancements of mbuf clones
On 27/04/15 18:38, Thomas Monjalon wrote: > 2015-04-24 11:38, Zoltan Kiss: >> On 22/04/15 12:59, Ananyev, Konstantin wrote: >>> From: Olivier Matz [mailto:olivier.matz at 6wind.com] >>> Sent: Wednesday, April 22, 2015 10:57 AM The first objective of this series is to fix the support of indirect mbufs when the application reserves a private area in mbufs. It also removes the limitation that rte_pktmbuf_clone() is only allowed on direct (non-cloned) mbufs. The series also contains some enhancements and fixes in the mbuf area that makes the implementation of the last patches easier. >>> >>> Acked-by: Konstantin Ananyev >> >> When does this series get merged? > > It was acked on April 22 and your question was 2 days later on April 24. > Does it mean you are expecting it to be merged the day it is acked? I was just curious about when to expect it, so I can plan to do some further work based on it, but nothing pressing. Regards, Zoltan > Or do you fear the merging because of a local dev you are working on? > Anyway, everybody seems happy with this version so it's going to be merged. >
[dpdk-dev] Performance regression in DPDK 1.8/2.0
> -Original Message- > From: Paul Emmerich [mailto:emmericp at net.in.tum.de] > Sent: Monday, April 27, 2015 11:29 PM > To: De Lara Guarch, Pablo > Cc: Pavel Odintsov; dev at dpdk.org > Subject: Re: [dpdk-dev] Performance regression in DPDK 1.8/2.0 > > Hi, > > Pablo : > > Could you tell me how you got the L1 cache miss ratio? Perf? > > perf stat -e L1-dcache-loads,L1-dcache-misses l2fwd ... > > > > Could you provide more information on how you run the l2fwd app, > > in order to try to reproduce the issue: > > - L2fwd Command line > > ./build/l2fwd -c 3 -n 2 -- -p 3 -q 2 > > > > - L2fwd initialization (to check memory/CPU/NICs) > > I unfortunately did not save the output, but I wrote down the important > parts: > > 1.7.1: no output regarding rx/tx code paths as init debug wasn't enabled > 1.8.0 and 2.0.0: simple tx code path, vector rx > > > Hardware: > > CPU: Intel(R) Xeon(R) CPU E3-1230 v2 > TurboBoost and HyperThreading disabled. > Frequency fixed at 3.30 GHz via acpi_cpufreq. > > NIC: X540-T2 > > Memory: Dual Channel DDR3 1333 MHz, 4x 4GB > > > Did you change the l2fwd app between versions? L2fwd uses simple rx on > 1.7.1, > > whereas it uses vector rx on 2.0 (enable IXGBE_DEBUG_INIT to check it). > > Yes, I had to update l2fwd when going from 1.7.1 to 1.8.0. However, the > changes in the app were minimal. Could you tell me which changes you made here? I see you are using simple tx code path on 1.8.0, but with the default values, you should be using vector tx, unless you have changed anything in the tx configuration. Not sure also if you are using simple tx code path on 1.7.1 then, plus scattered rx. (Without changing the l2fwd app, I use scattered rx and vector tx). Thanks! Pablo > > 1.8.0 and 2.0.0 used vector rx. Disabling vector rx via DPDK .config file > causes another 30% performance loss so I kept it enabled. > > > > > Which packet format/size did you use? Does your traffic generator take > into account the Inter-packet gap? > > 64 Byte packets, full line rate on both ports, i.e. 14.88 Mpps per port. > The packet's content doesn't matter as l2fwd doesn't look at it, but it was > just some random stuff: EthType 0x1234. > > > Let me know if you need any additional information. > I'd also be interested in the configuration that resulted in the 20% speed- > up that was mentioned in the original mbuf patch > > Paul
[dpdk-dev] Performance regression in DPDK 1.8/2.0
> -Original Message- > From: Richardson, Bruce > Sent: Tuesday, April 28, 2015 11:55 AM > To: Paul Emmerich > Cc: De Lara Guarch, Pablo; dev at dpdk.org > Subject: Re: [dpdk-dev] Performance regression in DPDK 1.8/2.0 > > On Tue, Apr 28, 2015 at 12:43:16PM +0200, Paul Emmerich wrote: > > Hi, > > > > sorry, I mixed up the hardware I used for my tests. > > > > > > Paul Emmerich : > > > CPU: Intel(R) Xeon(R) CPU E3-1230 v2 > > > TurboBoost and HyperThreading disabled. > > > Frequency fixed at 3.30 GHz via acpi_cpufreq. > > > > The CPU frequency was fixed at 1.60 GHz to enforce > > a CPU bottleneck. > > > > > > My original post said that I used a Xeon E5-2620 v3 > > at 1.2 GHz, this is incorrect. The calculation for Cycles/Pkt > > in the original post used the correct 1.6 GHz figure, though. > > > > (I used the E5 CPU for the evaluation of my packet generator > > performance with 1.7.1/2.0.0, not for the l2fwd test.) Thanks for the update. So, just for clarification, for l2fwd you used E3-1230 v2 (Ivy Bridge), at 1.6 GHz or 3.3 GHz? Pablo > > > > > > Sorry for the confusion. > > > > > > Paul > Thanks for the update - we are investigating. > > /Bruce
[dpdk-dev] Performance regression in DPDK 1.8/2.0
Hi, De Lara Guarch, Pablo : > Could you tell me which changes you made here? I see you are using simple tx > code path on 1.8.0, > but with the default values, you should be using vector tx, > unless you have changed anything in the tx configuration. sorry, I might have written that down wrong or read the output wrong. I did not modify the l2fwd example. > So, just for clarification, > for l2fwd you used E3-1230 v2 (Ivy Bridge), at 1.6 GHz or 3.3 GHz? At 1.6 GHz as it is simply too fast at 3.3 GHz ;) I?ll probably write a minimal example that shows my problem with tx only sometime next week. I just used the l2fwd example to illustrate my point with a 'builtin? example. Paul
[dpdk-dev] SR-IOV: ixgbe spoofed packets
Hey All, I hope that this is the right address for my question. I currently have a VM on Cisco server that runs KVM and SR-IOV is enabled. 4 VFs are attached to this VM and I try to send ARPs from SPIRENT traffic generator to the VM which its ports are VLAN tagged. Although I turned off spoof checking on the VFs (I used 'ip link set eth17 vf 0 spoofchk off' command), I still get spoofed packets detected on the ixgbe driver in dmesg: ixgbe ::0c:00.0 eth17: 2 Spoofed packets detected I read online that spoof detection is enabled by default (on compilation) on ixgbe driver when SR-IOV is active. Any idea how to overcome this issue? If any more information needed please let me know. Thanks, Shaham
[dpdk-dev] [PATCH 0/3] pcap pmd improvements
> -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: Tuesday, April 28, 2015 11:10 AM > To: Nicol?s Pernas Maradei; Mcnamara, John > Cc: dev at dpdk.org; Tero Aho > Subject: Re: [dpdk-dev] [PATCH 0/3] pcap pmd improvements > > Please Nicolas, John, > could we have a review of these patches? Will do. John. --
[dpdk-dev] [PATCH] enic: remove use of rte_fdir_filter for key_len
> This patch removes the use of rte_fdir_filter from enic_clsf. > This also takes care of modifying the version and copyright string. > > Signed-off-by: Sujith Sankar Applied, thanks
[dpdk-dev] data copy in vhost-user
On 28/04/15 02:22, Xie, Huawei wrote: > > >> -Original Message- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Zoltan Kiss >> Sent: Tuesday, April 28, 2015 12:27 AM >> To: Nikita Kalyazin; dev at dpdk.org >> Subject: Re: [dpdk-dev] data copy in vhost-user >> >> >> >> On 27/04/15 12:54, Nikita Kalyazin wrote: >>> Hi, >>> >>> >>> As far as I understand, DPDK vhost-user implementation requires data copy >> for either RX or TX (rte_vhost_dequeue_burst() and >> rte_vhost_enqueue_burst()). It means that two data copies are needed to >> transfer a packet from one VM to another. >>> >>> Why is not it possible to eliminate one of the copies (e.g., >> rte_vhost_enqueue_burst() might set up a reference at vring descriptor to >> mbuf's data rather than copying the data)? > This had been added to the to-do list. We could delay the copy until the real > copy is needed. >> >> I'm just guessing, but in case of VM-to-VM traffic the receiving one >> could hold onto the buffer indefinitely, preventing the sender to reuse >> the buffer. That could lead to a DoS in some cases, and shutting down >> the sender would be also tricky. At least in case of Xen >> netback/netfront that's the reason. A reasonable solution for this >> problem is to make sure the buffer is swapped out with a copy after a >> finite time. > Do you mean we associate a timeout for the buffer? Yes, I think xen-netback had such a version once, but it was removed. As far as I know the overhead and complexity of handling these timeouts were too severe. I might be wrong about this, I don't know if this problem applies here as well or not. >> >> Regards, >> >> Zoltan
[dpdk-dev] [PATCH 0/3] pcap pmd improvements
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tero Aho > Sent: Friday, February 27, 2015 1:43 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH 0/3] pcap pmd improvements > > We have found it convenient to use pcap interfaces in early development > when speed does not matter. However, pcap interfaces use fixed values for > some properties like link status which makes it hard to simulate certain > conditions. > > Here's series of small improvements we have originally used on top of > v1.7.0 (now rebased to current master). Hi, Thanks for the patches. They seem useful. The patch files have converted tabs to whitespace so they don't apply cleanly without changing the leading whitespace back to tabs. Perhaps you can fix that in v2. John
[dpdk-dev] [PATCH] test-pmd fix default mbuf size
Latest mbuf changes (priv_size addition and related fixes) exposed small problem with testpmd default config: testpmd default mbuf size is exaclty 2KB, that causes ixgbe PMD to select scattered RX even for configs with 'normal' max packet length (max_rx_pkt_len == ETHER_MAX_LEN). Signed-off-by: Konstantin Ananyev --- app/test-pmd/testpmd.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/app/test-pmd/testpmd.h b/app/test-pmd/testpmd.h index 389fc24..037e7ec 100644 --- a/app/test-pmd/testpmd.h +++ b/app/test-pmd/testpmd.h @@ -48,7 +48,8 @@ * Default size of the mbuf data buffer to receive standard 1518-byte * Ethernet frames in a mono-segment memory buffer. */ -#define DEFAULT_MBUF_DATA_SIZE 2048 /**< Default size of mbuf data buffer. */ +#define DEFAULT_MBUF_DATA_SIZE (2048 + RTE_PKTMBUF_HEADROOM) +/**< Default size of mbuf data buffer. */ /* * The maximum number of segments per packet is used when creating -- 1.8.3.1
[dpdk-dev] [PATCH] eal: fix log level check
> According to the api, rte_log() / rte_vlog() are supposed to check the log > level > and type but they were not doing so. This check was only done in the RTE_LOG > macro while this macro is only there to remove log messages at build time. > > rte_log() always calls rte_vlog(), so move the check to rte_vlog() only. > > Signed-off-by: Jean Dao > Signed-off-by: David Marchand Applied, thanks
[dpdk-dev] [PATCH 1/3] pcap: utilize underlying real interface properties
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tero Aho
> Sent: Friday, February 27, 2015 1:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 1/3] pcap: utilize underlying real interface
> properties
>
> These changes set pcap interface mac address to the real underlying
> interface address instead of the default one. Also real interface link
> status, speed and duplex are reported when eth_link_update is called for
> the pcap interface.
>
> Signed-off-by: Tero Aho
> ...
> + /* get link status, speed and duplex from the underlying
> interface */
> +
> + strncpy(ifr.ifr_name, internals->if_name,
> sizeof(ifr.ifr_name)-1);
> + ifr.ifr_name[sizeof(ifr.ifr_name)-1] = 0;
> + if (!ioctl(internals->if_fd, SIOCGIFFLAGS, &ifr))
> + dev->data->dev_link.link_status = (ifr.ifr_flags
> + & IFF_UP) ? 1 : 0;
> +
> + cmd.cmd = ETHTOOL_GSET;
> + ifr.ifr_data = (void *)&cmd;
> + if (!ioctl(internals->if_fd, SIOCETHTOOL, &ifr)) {
> + dev->data->dev_link.link_speed =
> ethtool_cmd_speed(&cmd);
Hi Tero,
I can see the benefit of setting the link status and speed etc. but this method
seems a little fragile. What if there isn't an underlying interface, or all the
interfaces are already bound to DPDK? Also I don't think the ethtool calls will
work on FreeBSD as is.
So overall, I think this is a nack for this part of the patch. Perhaps a better
approach would be to provide a function so that the calling application can set
the parameters instead.
John
[dpdk-dev] [PATCH 2/3] pcap: add support for jumbo frames
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tero Aho
> Sent: Friday, February 27, 2015 1:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 2/3] pcap: add support for jumbo frames
>
> Extend eth_pcap_rx and eth_pcap_tx to support jumbo frames.
> On receive side read large packets into multiple mbufs and on the transmit
> side do the opposite.
>
> +eth_pcap_tx_jumbo(pcap_t *pcap,
> + struct rte_mbuf *mbuf) {
> + u_char data[ETHER_MAX_JUMBO_FRAME_LEN];
> + uint16_t data_len = 0;
> +
> + while (mbuf != NULL) {
> + /* There is no writev style function in libpcap, */
> + /* we unfortunately have to copy data to a buffer. */
> + rte_memcpy(data + data_len, rte_pktmbuf_mtod(mbuf, void
> *),
> + mbuf->data_len);
> + data_len += mbuf->data_len;
> + mbuf = mbuf->next;
> + }
Hi Tero,
Not sure if it is possible in practice to overflow
data[ETHER_MAX_JUMBO_FRAME_LEN] but there should probably be a check.
John.
--
[dpdk-dev] [PATCH 3/3] pcap: add byte and error counters into statistics
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tero Aho
> Sent: Friday, February 27, 2015 1:43 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH 3/3] pcap: add byte and error counters into
> statistics
>
> Added input/ouput byte counters into pcap interface statistics, also calls
> pcap_stats to add dropped packets into input errors.
>
> Signed-off-by: Tero Aho
> ---
> lib/librte_pmd_pcap/rte_eth_pcap.c | 37 +
>
> 1 file changed, 29 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_pmd_pcap/rte_eth_pcap.c
> b/lib/librte_pmd_pcap/rte_eth_pcap.c
> index 3f23f0a..1c472ac 100644
> --- a/lib/librte_pmd_pcap/rte_eth_pcap.c
> +++ b/lib/librte_pmd_pcap/rte_eth_pcap.c
> @@ -71,6 +71,7 @@ struct pcap_rx_queue {
> uint8_t in_port;
> struct rte_mempool *mb_pool;
> volatile unsigned long rx_pkts;
> + volatile unsigned long rx_octs;
Hi Tero,
The equivalent rx/tx_octs members in rte_eth_stats are called ibytes/obytes so
these variables should be called rx_bytes/tx_bytes for consistency.
Also, not really your issue, but do these members actually need to be volatile
for pcap?
Otherwise looks okay.
John.
--
[dpdk-dev] [PATCH] PCAP PMD fix: pcap_rx_queue/pcap_tx_queue should store it's own copy of name/type values
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Konstantin Ananyev > Sent: Thursday, April 23, 2015 3:33 PM > To: Ananyev, Konstantin; dev at dpdk.org > Subject: [dpdk-dev] [PATCH] PCAP PMD fix: pcap_rx_queue/pcap_tx_queue > should store it's own copy of name/type values > > pcap_rx_queue/pcap_tx_queue should store it's own copy of name/type > values, not the pointer to temporary allocated space. > > Signed-off-by: Konstantin Ananyev Acked-by: John Mcnamara --
[dpdk-dev] [PATCH v7] Restore support for virtio on FreeBSD
> Fixes: 8a312224bcde ("eal/bsd: fix fd leak")
>
> Closing /dev/io fd causes SIGBUS in inb/outb instructions
> as the process loses the IOPL privileges once the fd is closed:
> (gdb) bt
> 0 0x00492f2c in outb (port=49170, data=0 '\000')
> at /usr/include/machine/cpufunc.h:244
> 1 0x00492f7a in outb_p (data=0 '\000', port=49170)
> at /dpdk/dpdk-2.0.0/lib/librte_pmd_virtio/virtio_pci.h:211
> 2 0x0049328d in vtpci_set_status (hw=0x80331f380, status=0 '\000')
> at /dpdk/dpdk-2.0.0/lib/librte_pmd_virtio/virtio_pci.c:130
> 3 0x004931fe in vtpci_reset (hw=0x80331f380)
> at /dpdk/dpdk-2.0.0/lib/librte_pmd_virtio/virtio_pci.c:108
> 4 0x004a175e in eth_virtio_dev_init (eth_dev=0x831b80
> )
> at /dpdk/dpdk-2.0.0/lib/librte_pmd_virtio/virtio_ethdev.c:1150
> 5 0x00462c09 in rte_eth_dev_init (pci_drv=0x79d1a0 ,
> pci_dev=0x802417560) at /dpdk/dpdk-2.0.0/lib/librte_ether/rte_ethdev.c:326
> 6 0x0046f03f in rte_eal_pci_probe_one_driver (dr=0x79d1a0
> ,
> dev=0x802417560) at /dpdk/dpdk-2.0.0/lib/librte_eal/bsdapp/eal/eal_pci.c:487
> 7 0x00475b06 in pci_probe_all_drivers (dev=0x802417560)
> at /dpdk/dpdk-2.0.0/lib/librte_eal/common/eal_common_pci.c:116
> 8 0x00475bb9 in rte_eal_pci_probe ()
> at /dpdk/dpdk-2.0.0/lib/librte_eal/common/eal_common_pci.c:246
> 9 0x0046cd63 in rte_eal_init (argc=5, argv=0x7fffeaf0)
> at /dpdk/dpdk-2.0.0/lib/librte_eal/bsdapp/eal/eal.c:554
> 10 0x00404544 in main ()
>
> Signed-off-by: Raz Amir
Applied, thanks
[dpdk-dev] [PATCH v5 0/5] Refactor module `eventfd_link'
Huawei, Changchun, Any opinion about these patches? 2015-04-16 14:48, Pavel Boldin: > This patchset contains refactoring steps for the `eventfd_link' module > of the DPDK's `librte_vhost' part. > > The commit messages are updated to include `Signed-off-by'. > > Pavel Boldin (5): > vhost: eventfd_link: moving ioctl to a function > vhost: eventfd_link: add function fget_from_files > vhost: eventfd_link: fix ioctl return values > vhost: eventfd_link: replace copy-pasted sys_close > vhost: eventfd_link: removing extra #includes > > lib/librte_vhost/eventfd_link/eventfd_link.c | 181 > +-- > 1 file changed, 87 insertions(+), 94 deletions(-)
[dpdk-dev] i40e and RSS woes
Hi Gleb I don't think the fix is in the master branch. I will double check it and get back to you later. Thank you very much for the reminder! Regards, Helin > -Original Message- > From: Gleb Natapov [mailto:gleb at cloudius-systems.com] > Sent: Tuesday, April 28, 2015 5:21 PM > To: Zhang, Helin > Cc: dev at dpdk.org > Subject: Re: i40e and RSS woes > > Hi, > > I didn't follow DPDK development to close lately. Was those problem fixed > already? > > On Thu, Mar 05, 2015 at 06:56:14AM +, Zhang, Helin wrote: > > > > > > > -Original Message- > > > From: Gleb Natapov [mailto:gleb at cloudius-systems.com] > > > Sent: Thursday, March 5, 2015 2:39 PM > > > To: Zhang, Helin > > > Cc: dev at dpdk.org > > > Subject: Re: i40e and RSS woes > > > > > > On Thu, Mar 05, 2015 at 05:56:27AM +, Zhang, Helin wrote: > > > > Hi Gleb > > > > > > > > Sorry for late! I am struggling on my tasks for the following DPDK > > > > release > > > these days. > > > > > > > > > -Original Message- > > > > > From: Gleb Natapov [mailto:gleb at cloudius-systems.com] > > > > > Sent: Monday, March 2, 2015 8:56 PM > > > > > To: dev at dpdk.org > > > > > Cc: Zhang, Helin > > > > > Subject: Re: i40e and RSS woes > > > > > > > > > > Ping. > > > > > > > > > > On Thu, Feb 19, 2015 at 04:50:10PM +0200, Gleb Natapov wrote: > > > > > > CCing i40e driver author in a hope to get an answer. > > > > > > > > > > > > On Mon, Feb 16, 2015 at 03:36:54PM +0200, Gleb Natapov wrote: > > > > > > > I have an application that works reasonably well with ixgbe > > > > > > > driver, but when I try to use it with i40e I encounter > > > > > > > various RSS related > > > issues. > > > > > > > > > > > > > > First one is that for some reason i40e, when it builds > > > > > > > default reta table, round down number of queues to power of > > > > > > > two. Why is this? If > > > > It seems because of i40e queue configuration. We will check it > > > > more and see if it can be changed or improved later. > > > > > > > Thanks, as I said below when I configure reta by myself everything > > > work as expected - traffic is received on all queues, so I am > > > curious if in some scenarios my code can break. > > > > > > > > > > I configure reta by my own using all of the queues > > > > > > > everything seams to be working. To add insult to injury I do > > > > > > > not get any errors during configuration some queues just do not > receive any traffic. > > > > > > > > > > > > > > The second problem is that for some reason i40e does not use > > > > > > > 40 byte toeplitz hash key like any other driver, but it > > > > > > > expects the key to be 52 bytes. And it would have being fine > > > > > > > (if we ignore the fact that it contradicts MS spec), but how > > > > > > > my high level code suppose to know > > > > > that? > > > > Actually a rss_key_len was introduced in struct rte_eth_rss_conf > > > > recently. So the length should be indicated clearly. But I found > > > > the annotations of that structure should have been reworked. I > > > > will try to rework > > > it with clear descriptions. > > > > > > > I saw rss_key_len of course, my question is how my code suppose to > > > know what value to set it to? Why required key length is not part of > > > a device capability query (or is it and I missed it)? The only way I > > > found to get key length is to quire device for a key, and check > > > rss_key_len. If it is zero then key is 40 bytes, otherwise whatever > > > rss_key_len says. This method is more of a hack then proper way to do it. > > I think it was missed. I will add it soon later. > > > > > > > > > > > > And again, device configuration does not fail when wrong key > > > > > > > length is provided, it just uses some other key. Guys this > > > > > > > kind of error handling is completely unacceptable. > > > > If less length of key is provided, it will not be used at all, the > > > > default key will be > > > used. > > > > So there is no issue as you said. But we need to add more clear > > > > description for the structure of rte_eth_rss_conf. > > > > > > > What you've said above is exactly the issue! My code does not work > > > if a key used by HW is not the same as was set by application, but > > > since I get no error when my setting is ignored the is not way for > > > me to know that my application will not work (short of querying key back > and comparing which is again a hack). > > > Device configuration should fail if it cannot apply my settings. > > After I checked the code, different PMD may have different implementation. > > Returning with an error might be the best way for all PMDs. I will unify it > later. > > > > Really good findings and suggestions from you! Thank you very much! > > > > -- > Gleb.
[dpdk-dev] [RFC PATCH] Simplify the ifdefs in rte.app.mk.
Trying to simplify the ifdefs in rte.app.mk to make the code more readable and maintainable by moving LDLIBS variable to use the same style as LDLIBS-y being used in the rest of the code. Signed-off-by: Keith Wiles --- mk/rte.app.mk | 253 ++ mk/rte.hostapp.mk | 4 +- mk/rte.shared.mk | 12 +-- 3 files changed, 74 insertions(+), 195 deletions(-) diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 62a76ae..af38975 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -1,7 +1,7 @@ # BSD LICENSE # -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# Copyright(c) 2014 6WIND S.A. +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +# Copyright(c) 2015 6WIND S.A. # All rights reserved. # # Redistribution and use in source and binary forms, with or without @@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) endif # default path for libs -LDLIBS += -L$(RTE_SDK_BIN)/lib +LDLIBS-y = -L$(RTE_SDK_BIN)/lib # # Include libraries depending on config if NO_AUTOLIBS is not set @@ -59,215 +59,94 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib # ifeq ($(NO_AUTOLIBS),) -LDLIBS += --whole-archive +LDLIBS-y += --whole-archive -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) -LDLIBS += -l$(RTE_LIBNAME) -endif +LDLIBS-CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME) ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) -ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) -LDLIBS += -lrte_distributor -endif - -ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) -LDLIBS += -lrte_reorder -endif - -ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_kni -endif -endif - -ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_ivshmem -endif -endif - -ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) -LDLIBS += -lrte_pipeline -endif - -ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) -LDLIBS += -lrte_table -endif - -ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) -LDLIBS += -lrte_port -endif - -ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) -LDLIBS += -lrte_timer -endif - -ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) -LDLIBS += -lrte_hash -endif - -ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) -LDLIBS += -lrte_jobstats -endif - -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) -LDLIBS += -lrte_lpm -endif - -ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) -LDLIBS += -lrte_power -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR)+= -lrte_distributor +LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER)+= -lrte_reorder -ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) -LDLIBS += -lrte_acl +ifeq ($( CONFIG_RTE_EXEC_ENV_LINUXAPP),y) +LDLIBS-$(CONFIG_RTE_LIBRTE_KNI)+= -lrte_kni +LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM)+= -lrte_ivshmem endif -ifeq ($(CONFIG_RTE_LIBRTE_METER),y) -LDLIBS += -lrte_meter -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline +LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table +LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port +LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer +LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash +LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats +LDLIBS-$(CONFIG_RTE_LIBRTE_LPM)+= -lrte_lpm +LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power +LDLIBS-$(CONFIG_RTE_LIBRTE_ACL)+= -lrte_acl +LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter -ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) -LDLIBS += -lrte_sched -LDLIBS += -lm -LDLIBS += -lrt -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) -LDLIBS += -lrte_vhost -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS -ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) -LDLIBS += -lpcap -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap ifeq ($(CONFIG_RTE_LIBRTE_VHOST)$(CONFIG_RTE_LIBRTE_VHOST_USER),yn) -LDLIBS += -lfuse +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lfuse endif -ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y) -LDLIBS += -libverbs -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs -LDLIBS += --start-group +LDLIBS-y += --start-group ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) -ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y) -LDLIBS += -lrte_kvargs -endif - -ifeq ($(CONFIG_RTE_LIBRTE_MBUF),y) -LDLIBS += -lrte_mbuf -endif - -ifeq ($(CONFIG_RTE_LIBRTE_IP_FRAG),y) -LDLIBS += -lrte_ip_frag -endif - -ifeq ($(CONFIG_RTE_LIBRTE_ETHER),y) -LDLIBS += -lethdev -endif - -ifeq ($(CONFIG_RTE_LIBRTE_MALLOC),y) -LDLIBS += -lrte_malloc -endif - -ifeq ($(CONFIG_RTE_LIBRTE_MEMPOOL),y) -LDLIBS += -lrte_mempool -endif - -ifeq ($(CONFIG_RTE_LIBRTE_RING),y) -LDLIBS += -lrte_ring -endif
[dpdk-dev] [RFC PATCH] Simplify the ifdefs in rte.app.mk.
I have not tested this change more then just building DPDK with GCC. On 4/28/15, 10:21 AM, "Keith Wiles" wrote: >Trying to simplify the ifdefs in rte.app.mk to make the code >more readable and maintainable by moving LDLIBS variable to use >the same style as LDLIBS-y being used in the rest of the code. > >Signed-off-by: Keith Wiles >--- > mk/rte.app.mk | 253 >++ > mk/rte.hostapp.mk | 4 +- > mk/rte.shared.mk | 12 +-- > 3 files changed, 74 insertions(+), 195 deletions(-) > >diff --git a/mk/rte.app.mk b/mk/rte.app.mk >index 62a76ae..af38975 100644 >--- a/mk/rte.app.mk >+++ b/mk/rte.app.mk >@@ -1,7 +1,7 @@ > # BSD LICENSE > # >-# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. >-# Copyright(c) 2014 6WIND S.A. >+# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. >+# Copyright(c) 2015 6WIND S.A. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without >@@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) > endif > > # default path for libs >-LDLIBS += -L$(RTE_SDK_BIN)/lib >+LDLIBS-y = -L$(RTE_SDK_BIN)/lib > > # > # Include libraries depending on config if NO_AUTOLIBS is not set >@@ -59,215 +59,94 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib > # > ifeq ($(NO_AUTOLIBS),) > >-LDLIBS += --whole-archive >+LDLIBS-y += --whole-archive > >-ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) >-LDLIBS += -l$(RTE_LIBNAME) >-endif >+LDLIBS-CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME) > > ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) > >-ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) >-LDLIBS += -lrte_distributor >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) >-LDLIBS += -lrte_reorder >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) >-ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >-LDLIBS += -lrte_kni >-endif >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) >-ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >-LDLIBS += -lrte_ivshmem >-endif >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) >-LDLIBS += -lrte_pipeline >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) >-LDLIBS += -lrte_table >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) >-LDLIBS += -lrte_port >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) >-LDLIBS += -lrte_timer >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) >-LDLIBS += -lrte_hash >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) >-LDLIBS += -lrte_jobstats >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) >-LDLIBS += -lrte_lpm >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) >-LDLIBS += -lrte_power >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor >+LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder > >-ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) >-LDLIBS += -lrte_acl >+ifeq ($( CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >+LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni >+LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += -lrte_ivshmem > endif > >-ifeq ($(CONFIG_RTE_LIBRTE_METER),y) >-LDLIBS += -lrte_meter >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline >+LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table >+LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port >+LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer >+LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash >+LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats >+LDLIBS-$(CONFIG_RTE_LIBRTE_LPM) += -lrte_lpm >+LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power >+LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += -lrte_acl >+LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter > >-ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) >-LDLIBS += -lrte_sched >-LDLIBS += -lm >-LDLIBS += -lrt >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched >+LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm >+LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt > >-ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) >-LDLIBS += -lrte_vhost >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost > > endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS > >-ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) >-LDLIBS += -lpcap >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap > > ifeq ($(CONFIG_RTE_LIBRTE_VHOST)$(CONFIG_RTE_LIBRTE_VHOST_USER),yn) >-LDLIBS += -lfuse >+LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lfuse > endif > >-ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y) >-LDLIBS += -libverbs >-endif >+LDLIBS-$(CONFIG_RTE_LIBRTE_MLX4_PMD) += -libverbs > >-LDLIBS += --start-group >+LDLIBS-y += --start-group > > ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) > >-ifeq ($(CONFIG_RTE_LIBRTE_KVARGS),y) >-LDLIBS += -lrte_kvargs >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_MBUF),y) >-LDLIBS += -lrte_mbuf >-endif >- >-ifeq ($(CONFIG_RTE_LIBRTE_IP_FRAG),y) >-LDLIBS += -lrte_ip_frag >-en
[dpdk-dev] [PATCH 0/3] port: added frag_ipv6 and ras_ipv6 ports
> Acked by: Cristian Dumitrescu Cristian, you forgot my previous recommendation: http://dpdk.org/ml/archives/dev/2015-February/013818.html A patch without Signed-off cannot be applied. Maciej, looking at your several series, most of these 30 patches have no signed-off nor commit messages. Reminder: a commit message must summarize the goal of the patch and explain why it is needed. Thanks for submitting new versions.
[dpdk-dev] [PATCH] igb: handle VF LPE mailbox message
> > This patch adds the handle function for the LPE mailbox message (VF to > > PF) to set maximum packet size, which can be used to enable jumbo > > frame support. > > > > Signed-off-by: Sergio Gonzalez Monroy > > Acked-by: Konstantin Ananyev Applied, thanks
[dpdk-dev] [RFC PATCH] Simplify the ifdefs in rte.app.mk.
On 28/04/2015 16:21, Keith Wiles wrote: > Trying to simplify the ifdefs in rte.app.mk to make the code > more readable and maintainable by moving LDLIBS variable to use > the same style as LDLIBS-y being used in the rest of the code. > > Signed-off-by: Keith Wiles > --- +1 Patch looks good, just a few nits: > mk/rte.app.mk | 253 > ++ > mk/rte.hostapp.mk | 4 +- > mk/rte.shared.mk | 12 +-- > 3 files changed, 74 insertions(+), 195 deletions(-) > > diff --git a/mk/rte.app.mk b/mk/rte.app.mk > index 62a76ae..af38975 100644 > --- a/mk/rte.app.mk > +++ b/mk/rte.app.mk > @@ -1,7 +1,7 @@ > # BSD LICENSE > # > -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. > -# Copyright(c) 2014 6WIND S.A. > +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. > +# Copyright(c) 2015 6WIND S.A. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without > @@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) > endif > > # default path for libs > -LDLIBS += -L$(RTE_SDK_BIN)/lib > +LDLIBS-y = -L$(RTE_SDK_BIN)/lib > I think we should keep the current value of LDLIBS. Some apps (ie. examples/dpdk_qat ) preset LDLIBS before including rte.app.mk. > # > # Include libraries depending on config if NO_AUTOLIBS is not set > @@ -59,215 +59,94 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib > # > ifeq ($(NO_AUTOLIBS),) > > -LDLIBS += --whole-archive > +LDLIBS-y += --whole-archive > > -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) > -LDLIBS += -l$(RTE_LIBNAME) > -endif > +LDLIBS-CONFIG_RTE_BUILD_COMBINE_LIBS)+= -l$(RTE_LIBNAME) > I think here is missing $( before CONFIG. > ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) > > -ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) > -LDLIBS += -lrte_distributor > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) > -LDLIBS += -lrte_reorder > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) > -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > -LDLIBS += -lrte_kni > -endif > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) > -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > -LDLIBS += -lrte_ivshmem > -endif > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) > -LDLIBS += -lrte_pipeline > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) > -LDLIBS += -lrte_table > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) > -LDLIBS += -lrte_port > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) > -LDLIBS += -lrte_timer > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) > -LDLIBS += -lrte_hash > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) > -LDLIBS += -lrte_jobstats > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) > -LDLIBS += -lrte_lpm > -endif > - > -ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) > -LDLIBS += -lrte_power > -endif > +LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor > +LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder > > -ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) > -LDLIBS += -lrte_acl > +ifeq ($( CONFIG_RTE_EXEC_ENV_LINUXAPP),y) > +LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni > +LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += -lrte_ivshmem > endif > > -ifeq ($(CONFIG_RTE_LIBRTE_METER),y) > -LDLIBS += -lrte_meter > -endif > +LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE) += -lrte_pipeline > +LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE)+= -lrte_table > +LDLIBS-$(CONFIG_RTE_LIBRTE_PORT) += -lrte_port > +LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER)+= -lrte_timer > +LDLIBS-$(CONFIG_RTE_LIBRTE_HASH) += -lrte_hash > +LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS) += -lrte_jobstats > +LDLIBS-$(CONFIG_RTE_LIBRTE_LPM) += -lrte_lpm > +LDLIBS-$(CONFIG_RTE_LIBRTE_POWER)+= -lrte_power > +LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += -lrte_acl > +LDLIBS-$(CONFIG_RTE_LIBRTE_METER)+= -lrte_meter > > -ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) > -LDLIBS += -lrte_sched > -LDLIBS += -lm > -LDLIBS += -lrt > -endif > +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)+= -lrte_sched > +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)+= -lm > +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED)+= -lrt > > -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) > -LDLIBS += -lrte_vhost > -endif > +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)+= -lrte_vhost > > endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS > > -ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) > -LDLIBS += -lpcap > -endif > +LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_PCAP) += -lpcap > > ifeq ($(CONFIG_RTE_LIBRTE_VHOST)$(CONFIG_RTE_LIBRTE_VHOST_USER),yn) > -LDLIBS += -lfuse > +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST)+= -lfuse > endif We could remove $(CONFIG_RTE_LIBRTE_VHOST) from the ifeq. > > -ifeq ($(CONFIG_RTE_LIBRTE_MLX4_PMD),y) > -LDLIBS += -libverbs > -endif > +LDLIBS-$(C
[dpdk-dev] What to do about UIO breakage in 2.0
On Tue, 28 Apr 2015 08:07:18 + "Qiu, Michael" wrote: > On 4/28/2015 6:06 AM, Stephen Hemminger wrote: > > I raised the issue, but people seem to be ignoring that fact that igb_uio > > was broken by the introduction of UIO PCI generic in 2.0. > > What do you mean about igb_uio broken? > > Thanks, > Michael > > > > There are three options: > > 1. Remove IGB_UIO only use UIO PCI generic. > > Downside there is no MSI-X support for UIO PCI generic. > > 2. Revert UIO PCI generic support > > 3. Replace both of the above with something better. > > > > I am working on #3 but it will not be ready for 2.0.1 and there > > is no solution for users of 2.0 and any future stable code. > > > If you use link state interrupt, then the base code in eal_interrupts is now broken when using igb_uio. The code was changed to work with uio_pci_generic. The new code does read/write of PCI INTX config and will not work when using igb_uio which uses MSI-X. Some possible solutions are: 1. Remove igb_uio completely 2. Revert/remove uio_pci_generic and use old read/write to enable irq 3. Make code look at driver type (sending patches for that now). 4. Implement a better UIO method for MSI-X which is what I will submit when Rx IRQ support is ready.
[dpdk-dev] [PATCH 1/3] uio: fix irq handling with igb_uio
The introduction of uio_pci_generic broke interrupt handling with
igb_uio. The igb_uio device uses the kernel read/write method to
enable disable IRQ's; the uio_pci_generic has to use PCI intx
config read/write to enable disable interrupts.
Since igb_uio uses MSI-X the PCI intx config read/write won't
work.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 40 --
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 15 +---
.../linuxapp/eal/include/exec-env/rte_interrupts.h | 3 +-
3 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 66deda2..3a84b3c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -361,7 +361,7 @@ vfio_disable_msix(struct rte_intr_handle *intr_handle) {
#endif
static int
-uio_intr_disable(struct rte_intr_handle *intr_handle)
+uio_intx_intr_disable(struct rte_intr_handle *intr_handle)
{
unsigned char command_high;
@@ -385,7 +385,7 @@ uio_intr_disable(struct rte_intr_handle *intr_handle)
}
static int
-uio_intr_enable(struct rte_intr_handle *intr_handle)
+uio_intx_intr_enable(struct rte_intr_handle *intr_handle)
{
unsigned char command_high;
@@ -408,6 +408,34 @@ uio_intr_enable(struct rte_intr_handle *intr_handle)
return 0;
}
+static int
+uio_intr_disable(struct rte_intr_handle *intr_handle)
+{
+ const int value = 0;
+
+ if (write(intr_handle->fd, &value, sizeof(value)) < 0) {
+ RTE_LOG(ERR, EAL,
+ "Error disabling interrupts for fd %d (%s)\n",
+ intr_handle->fd, strerror(errno));
+ return -1;
+ }
+ return 0;
+}
+
+static int
+uio_intr_enable(struct rte_intr_handle *intr_handle)
+{
+ const int value = 1;
+
+ if (write(intr_handle->fd, &value, sizeof(value)) < 0) {
+ RTE_LOG(ERR, EAL,
+ "Error enabling interrupts for fd %d (%s)\n",
+ intr_handle->fd, strerror(errno));
+ return -1;
+ }
+ return 0;
+}
+
int
rte_intr_callback_register(struct rte_intr_handle *intr_handle,
rte_intr_callback_fn cb, void *cb_arg)
@@ -556,6 +584,10 @@ rte_intr_enable(struct rte_intr_handle *intr_handle)
if (uio_intr_enable(intr_handle))
return -1;
break;
+ case RTE_INTR_HANDLE_UIO_INTX:
+ if (uio_intx_intr_enable(intr_handle))
+ return -1;
+ break;
/* not used at this moment */
case RTE_INTR_HANDLE_ALARM:
return -1;
@@ -596,6 +628,10 @@ rte_intr_disable(struct rte_intr_handle *intr_handle)
if (uio_intr_disable(intr_handle))
return -1;
break;
+ case RTE_INTR_HANDLE_UIO_INTX:
+ if (uio_intx_intr_disable(intr_handle))
+ return -1;
+ break;
/* not used at this moment */
case RTE_INTR_HANDLE_ALARM:
return -1;
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
index 2d1c69b..b5116a7 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
@@ -299,7 +299,6 @@ pci_uio_map_resource(struct rte_pci_device *dev)
devname, strerror(errno));
return -1;
}
- dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
snprintf(cfgname, sizeof(cfgname),
"/sys/class/uio/uio%u/device/config", uio_num);
@@ -310,10 +309,16 @@ pci_uio_map_resource(struct rte_pci_device *dev)
return -1;
}
- /* set bus master that is not done by uio_pci_generic */
- if (pci_uio_set_bus_master(dev->intr_handle.uio_cfg_fd)) {
- RTE_LOG(ERR, EAL, "Cannot set up bus mastering!\n");
- return -1;
+ if (dev->kdrv == RTE_KDRV_IGB_UIO)
+ dev->intr_handle.type = RTE_INTR_HANDLE_UIO;
+ else {
+ dev->intr_handle.type = RTE_INTR_HANDLE_UIO_INTX;
+
+ /* set bus master that is not done by uio_pci_generic */
+ if (pci_uio_set_bus_master(dev->intr_handle.uio_cfg_fd)) {
+ RTE_LOG(ERR, EAL, "Cannot set up bus mastering!\n");
+ return -1;
+ }
}
/* allocate the mapping details for secondary processes*/
diff --git a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
index 6a159c7..bdeb3fc 100644
--- a/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
+++ b/lib/librte_eal/linuxapp/eal/include/exec-env/rte_interrupts.h
@@ -40,7 +40,8 @@
enum rte_intr_handle_
[dpdk-dev] [PATCH 0/3] eal: uio irq fixes and enhancements
This set of patches starts out with fixing a regression where uio_pci_generic broke link state interrupt, then adds better management of PCI config space. Will leave up to document writers to update various release notes and API manuals as they see fit. Also, needs what ever shared library map file updates which maybe required when using dynamic libraries. But that should not stop acceptance of this patch set. Stephen Hemminger (3): uio: fix irq handling with igb_uio pci: add ability to read/write config space eal: use pci_uio_read/write config to enable/disable INTX lib/librte_eal/bsdapp/eal/eal_pci.c| 76 ++ lib/librte_eal/common/include/rte_pci.h| 29 + lib/librte_eal/linuxapp/eal/eal_interrupts.c | 70 lib/librte_eal/linuxapp/eal/eal_pci.c | 50 ++ lib/librte_eal/linuxapp/eal/eal_pci_init.h | 11 lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 29 +++-- lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 16 + .../linuxapp/eal/include/exec-env/rte_interrupts.h | 3 +- 8 files changed, 264 insertions(+), 20 deletions(-) -- 2.1.4
[dpdk-dev] [PATCH 2/3] pci: add ability to read/write config space
Add new ability to read/write PCI registers in device.
This is needed by BNX2X driver and is generally useful
for other code.
The BSD code has not been tested but is included to show
how the feature is cross-platform.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/bsdapp/eal/eal_pci.c| 76 ++
lib/librte_eal/common/include/rte_pci.h| 29
lib/librte_eal/linuxapp/eal/eal_pci.c | 50
lib/librte_eal/linuxapp/eal/eal_pci_init.h | 11 +
lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 14 ++
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 16 +++
6 files changed, 196 insertions(+)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 30f0232..b104e5f 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -490,6 +490,82 @@ rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *d
return 1;
}
+/* Read PCI config space. */
+int rte_eal_pci_read_config(const struct rte_pci_device *dev,
+ void *buf, size_t len, off_t offset)
+{
+ struct pci_io io = {
+ .pi_sel = {
+ .pc_domain = dev->addr.domain,
+ .pc_bus = dev->addr.bus,
+ .pc_dev = dev->addr.devid,
+ .pc_func = dev->addr.function,
+ },
+ .pi_reg = offset,
+ .pi_width = len;
+ };
+
+ if (len == 0 || len > sizeof(io.pi_data)) {
+ RTE_LOG(ERR, EAL, "%s(): invalid register length\n", __func__);
+ return -1;
+ }
+
+ fd = open("/dev/pci", O_RDONLY);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+ return -1;
+ }
+
+ if (ioctl(fd, PCIOCREAD, &io) < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
+ __func__, strerror(errno));
+ close(fd);
+ return -1;
+ }
+
+ close(fd);
+ memcpy(buf, io.pi_data, len);
+ return 0;
+}
+
+/* Write PCI config space. */
+int rte_eal_pci_write_config(const struct rte_pci_device *device,
+const void *buf, size_t len, off_t offset)
+{
+ struct pci_io io = {
+ .pi_sel = {
+ .pc_domain = dev->addr.domain,
+ .pc_bus = dev->addr.bus,
+ .pc_dev = dev->addr.devid,
+ .pc_func = dev->addr.function,
+ },
+ .pi_reg = offset,
+ .pi_width = len;
+ };
+
+ if (len == 0 || len > sizeof(io.pi_data)) {
+ RTE_LOG(ERR, EAL, "%s(): invalid register length\n", __func__);
+ return -1;
+ }
+ memcpy(io.pi_data, buf, len);
+
+ fd = open("/dev/pci", O_RDONLY);
+ if (fd < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error opening /dev/pci\n", __func__);
+ return -1;
+ }
+
+ if (ioctl(fd, PCIOCWRITE, &io) < 0) {
+ RTE_LOG(ERR, EAL, "%s(): error with ioctl on /dev/pci: %s\n",
+ __func__, strerror(errno));
+ close(fd);
+ return -1;
+ }
+
+ close(fd);
+ return 0;
+}
+
/* Init the PCI EAL subsystem */
int
rte_eal_pci_init(void)
diff --git a/lib/librte_eal/common/include/rte_pci.h
b/lib/librte_eal/common/include/rte_pci.h
index 223d3cd..f4836f6 100644
--- a/lib/librte_eal/common/include/rte_pci.h
+++ b/lib/librte_eal/common/include/rte_pci.h
@@ -393,6 +393,35 @@ void rte_eal_pci_register(struct rte_pci_driver *driver);
*/
void rte_eal_pci_unregister(struct rte_pci_driver *driver);
+
+/**
+ * Read PCI config space.
+ *
+ * @param device
+ * A pointer to a rte_pci_device structure describing the device
+ * to use
+ * @param buf
+ * A data buffer where the bytes should be read into
+ * @param size
+ * The length of the data buffer.
+ */
+int rte_eal_pci_read_config(const struct rte_pci_device *device,
+ void *buf, size_t len, off_t offset);
+
+/**
+ * Write PCI config space.
+ *
+ * @param device
+ * A pointer to a rte_pci_device structure describing the device
+ * to use
+ * @param buf
+ * A data buffer containing the bytes should be written
+ * @param size
+ * The length of the data buffer.
+ */
+int rte_eal_pci_write_config(const struct rte_pci_device *device,
+const void *buf, size_t len, off_t offset);
+
#ifdef __cplusplus
}
#endif
diff --git a/lib/librte_eal/linuxapp/eal/eal_pci.c
b/lib/librte_eal/linuxapp/eal/eal_pci.c
index d2adc66..4da59fe 100644
--- a/lib/librte_eal/linuxapp/eal/eal_pci.c
+++ b/lib/librte_eal/linuxapp/eal/eal_pci.c
@@ -756,6 +756,56 @@ rte_eal_pci_close_one_driver(struct rte_pci_driver *dr
__rte_unused,
}
#endif /* R
[dpdk-dev] [PATCH 3/3] eal: use pci_uio_read/write config to enable/disable INTX
Change the code use to enable/disable interrupts with UIO_PCI_GENERIC
driver. Instead of having magic constants for the PCI register values
use the standard defines available on Linux. Also use the new
routines available to peek/poke PCI config space.
Signed-off-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 30 +---
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index 3a84b3c..3a90944 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -41,6 +41,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -66,6 +67,7 @@
#include "eal_private.h"
#include "eal_vfio.h"
+#include "eal_pci_init.h"
#define EAL_INTR_EPOLL_WAIT_FOREVER (-1)
@@ -363,18 +365,20 @@ vfio_disable_msix(struct rte_intr_handle *intr_handle) {
static int
uio_intx_intr_disable(struct rte_intr_handle *intr_handle)
{
- unsigned char command_high;
+ uint16_t cmd;
- /* use UIO config file descriptor for uio_pci_generic */
- if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ if (pci_uio_read_config(intr_handle, &cmd, sizeof(cmd),
+ PCI_COMMAND) < 0) {
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) {
+
+ cmd |= PCI_COMMAND_INTX_DISABLE;
+
+ if (pci_uio_write_config(intr_handle, &cmd, sizeof(cmd),
+PCI_COMMAND) < 0) {
RTE_LOG(ERR, EAL,
"Error disabling interrupts for fd %d\n",
intr_handle->uio_cfg_fd);
@@ -387,18 +391,20 @@ uio_intx_intr_disable(struct rte_intr_handle *intr_handle)
static int
uio_intx_intr_enable(struct rte_intr_handle *intr_handle)
{
- unsigned char command_high;
+ uint16_t cmd;
- /* use UIO config file descriptor for uio_pci_generic */
- if (pread(intr_handle->uio_cfg_fd, &command_high, 1, 5) != 1) {
+ if (pci_uio_read_config(intr_handle, &cmd, sizeof(cmd),
+ PCI_COMMAND) < 0) {
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) {
+
+ cmd &= ~PCI_COMMAND_INTX_DISABLE;
+
+ if (pci_uio_write_config(intr_handle, &cmd, sizeof(cmd),
+PCI_COMMAND) < 0) {
RTE_LOG(ERR, EAL,
"Error enabling interrupts for fd %d\n",
intr_handle->uio_cfg_fd);
--
2.1.4
[dpdk-dev] KNI is broken with Linux 4.0
KNI won't build anymore. Since I don't use it not my problem.
CC [M] /var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.o
/var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error:
initialization from incompatible pointer type [-Werror]
.ndo_bridge_setlink = igb_ndo_bridge_setlink,
^
/var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.c:2321:2: error:
(near initialization for ?igb_netdev_ops.ndo_bridge_setlink?) [-Werror]
/var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.c: In function
?igb_xmit_frame_ring?:
/var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.c:5482:2: error:
implicit declaration of function ?vlan_tx_tag_present?
[-Werror=implicit-function-declaration]
if (vlan_tx_tag_present(skb)) {
^
/var/src/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.c:5484:3: error:
implicit declaration of function ?vlan_tx_tag_get?
[-Werror=implicit-function-declaration]
tx_flags |= (vlan_tx_tag_get(skb) << IGB_TX_FLAGS_VLAN_SHIFT);
^
cc1: all warnings being treated as errors
Ps: this and all the other kernel drivers really need to be upstream
to avoid these kind of issues in the future.
[dpdk-dev] [RFC PATCH] Simplify the ifdefs in rte.app.mk.
Hi Sergio On 4/28/15, 11:25 AM, "Gonzalez Monroy, Sergio" wrote: >On 28/04/2015 16:21, Keith Wiles wrote: >> Trying to simplify the ifdefs in rte.app.mk to make the code >> more readable and maintainable by moving LDLIBS variable to use >> the same style as LDLIBS-y being used in the rest of the code. >> >> Signed-off-by: Keith Wiles >> --- >+1 > >Patch looks good, just a few nits: >> mk/rte.app.mk | 253 >>++ >> mk/rte.hostapp.mk | 4 +- >> mk/rte.shared.mk | 12 +-- >> 3 files changed, 74 insertions(+), 195 deletions(-) >> >> diff --git a/mk/rte.app.mk b/mk/rte.app.mk >> index 62a76ae..af38975 100644 >> --- a/mk/rte.app.mk >> +++ b/mk/rte.app.mk >> @@ -1,7 +1,7 @@ >> # BSD LICENSE >> # >> -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. >> -# Copyright(c) 2014 6WIND S.A. >> +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. >> +# Copyright(c) 2015 6WIND S.A. >> # All rights reserved. >> # >> # Redistribution and use in source and binary forms, with or without >> @@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) >> endif >> >> # default path for libs >> -LDLIBS += -L$(RTE_SDK_BIN)/lib >> +LDLIBS-y = -L$(RTE_SDK_BIN)/lib >> >I think we should keep the current value of LDLIBS. >Some apps (ie. examples/dpdk_qat ) preset LDLIBS before including >rte.app.mk. I just modified the example apps to use a new VARIABLE called EXTRA_LDLIBS instead and added it towards the bottom of rte.app.mk. I think adding the EXTRA_LDLIBS is the right solution instead of using LDLIBS IMO. > >> # >> # Include libraries depending on config if NO_AUTOLIBS is not set >> @@ -59,215 +59,94 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib >> # >> ifeq ($(NO_AUTOLIBS),) >> >> -LDLIBS += --whole-archive >> +LDLIBS-y += --whole-archive >> >> -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) >> -LDLIBS += -l$(RTE_LIBNAME) >> -endif >> +LDLIBS-CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME) >> >I think here is missing $( before CONFIG. Ooops :-) > >> ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) >> >> -ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) >> -LDLIBS += -lrte_distributor >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) >> -LDLIBS += -lrte_reorder >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) >> -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >> -LDLIBS += -lrte_kni >> -endif >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) >> -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >> -LDLIBS += -lrte_ivshmem >> -endif >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) >> -LDLIBS += -lrte_pipeline >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) >> -LDLIBS += -lrte_table >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) >> -LDLIBS += -lrte_port >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) >> -LDLIBS += -lrte_timer >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) >> -LDLIBS += -lrte_hash >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) >> -LDLIBS += -lrte_jobstats >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) >> -LDLIBS += -lrte_lpm >> -endif >> - >> -ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) >> -LDLIBS += -lrte_power >> -endif >> +LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor >> +LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder >> >> -ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) >> -LDLIBS += -lrte_acl >> +ifeq ($( CONFIG_RTE_EXEC_ENV_LINUXAPP),y) >> +LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni >> +LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += -lrte_ivshmem >> endif >> >> -ifeq ($(CONFIG_RTE_LIBRTE_METER),y) >> -LDLIBS += -lrte_meter >> -endif >> +LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE)+= -lrte_pipeline >> +LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table >> +LDLIBS-$(CONFIG_RTE_LIBRTE_PORT)+= -lrte_port >> +LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer >> +LDLIBS-$(CONFIG_RTE_LIBRTE_HASH)+= -lrte_hash >> +LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS)+= -lrte_jobstats >> +LDLIBS-$(CONFIG_RTE_LIBRTE_LPM) += -lrte_lpm >> +LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power >> +LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += -lrte_acl >> +LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter >> >> -ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) >> -LDLIBS += -lrte_sched >> -LDLIBS += -lm >> -LDLIBS += -lrt >> -endif >> +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched >> +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm >> +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt >> >> -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) >> -LDLIBS += -lrte_vhost >> -endif >> +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost >> >> endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS >> >> -ifeq
[dpdk-dev] [PATCH] Simplify the ifdefs in rte.app.mk.
Trying to simplify the ifdefs in rte.app.mk to make the code more readable and maintainable by moving LDLIBS variable to use the same style as LDLIBS-y being used in the rest of the code. Added a new variable called EXTRA_LDLIBS to be used by example apps instead of using LDLIBS directly. Signed-off-by: Keith Wiles --- examples/dpdk_qat/Makefile | 4 +- examples/vm_power_manager/Makefile | 2 +- mk/rte.app.mk | 254 ++--- mk/rte.hostapp.mk | 4 +- mk/rte.shared.mk | 12 +- 5 files changed, 77 insertions(+), 199 deletions(-) diff --git a/examples/dpdk_qat/Makefile b/examples/dpdk_qat/Makefile index f1e06a1..90ca1d3 100644 --- a/examples/dpdk_qat/Makefile +++ b/examples/dpdk_qat/Makefile @@ -77,8 +77,8 @@ else ICP_LIBRARY_PATH = $(ICP_ROOT)/build/libicp_qa_al.a endif -LDLIBS += -L$(ICP_ROOT)/build -LDLIBS += $(ICP_LIBRARY_PATH) \ +EXTRA_LDLIBS += -L$(ICP_ROOT)/build +EXTRA_LDLIBS += $(ICP_LIBRARY_PATH) \ -lz \ -losal \ -ladf_proxy \ diff --git a/examples/vm_power_manager/Makefile b/examples/vm_power_manager/Makefile index 113dbc4..8fb78d4 100644 --- a/examples/vm_power_manager/Makefile +++ b/examples/vm_power_manager/Makefile @@ -48,7 +48,7 @@ SRCS-y += channel_monitor.c CFLAGS += -O3 -I$(RTE_SDK)/lib/librte_power/ CFLAGS += $(WERROR_FLAGS) -LDLIBS += -lvirt +EXTRA_LDLIBS += -lvirt # workaround for a gcc bug with noreturn attribute # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 diff --git a/mk/rte.app.mk b/mk/rte.app.mk index 62a76ae..ed471ad 100644 --- a/mk/rte.app.mk +++ b/mk/rte.app.mk @@ -1,7 +1,7 @@ # BSD LICENSE # -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# Copyright(c) 2014 6WIND S.A. +# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. +# Copyright(c) 2015 6WIND S.A. # All rights reserved. # # Redistribution and use in source and binary forms, with or without @@ -51,7 +51,7 @@ LDSCRIPT = $(RTE_LDSCRIPT) endif # default path for libs -LDLIBS += -L$(RTE_SDK_BIN)/lib +LDLIBS-y = -L$(RTE_SDK_BIN)/lib # # Include libraries depending on config if NO_AUTOLIBS is not set @@ -59,215 +59,93 @@ LDLIBS += -L$(RTE_SDK_BIN)/lib # ifeq ($(NO_AUTOLIBS),) -LDLIBS += --whole-archive +LDLIBS-y += --whole-archive -ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),y) -LDLIBS += -l$(RTE_LIBNAME) -endif +LDLIBS-$(CONFIG_RTE_BUILD_COMBINE_LIBS) += -l$(RTE_LIBNAME) ifeq ($(CONFIG_RTE_BUILD_COMBINE_LIBS),n) -ifeq ($(CONFIG_RTE_LIBRTE_DISTRIBUTOR),y) -LDLIBS += -lrte_distributor -endif - -ifeq ($(CONFIG_RTE_LIBRTE_REORDER),y) -LDLIBS += -lrte_reorder -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor +LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder -ifeq ($(CONFIG_RTE_LIBRTE_KNI),y) ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_kni -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_KNI) += -lrte_kni +LDLIBS-$(CONFIG_RTE_LIBRTE_IVSHMEM) += -lrte_ivshmem endif -ifeq ($(CONFIG_RTE_LIBRTE_IVSHMEM),y) -ifeq ($(CONFIG_RTE_EXEC_ENV_LINUXAPP),y) -LDLIBS += -lrte_ivshmem -endif -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_PIPELINE)+= -lrte_pipeline +LDLIBS-$(CONFIG_RTE_LIBRTE_TABLE) += -lrte_table +LDLIBS-$(CONFIG_RTE_LIBRTE_PORT)+= -lrte_port +LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer +LDLIBS-$(CONFIG_RTE_LIBRTE_HASH)+= -lrte_hash +LDLIBS-$(CONFIG_RTE_LIBRTE_JOBSTATS)+= -lrte_jobstats +LDLIBS-$(CONFIG_RTE_LIBRTE_LPM) += -lrte_lpm +LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power +LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += -lrte_acl +LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter -ifeq ($(CONFIG_RTE_LIBRTE_PIPELINE),y) -LDLIBS += -lrte_pipeline -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrte_sched +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lm +LDLIBS-$(CONFIG_RTE_LIBRTE_SCHED) += -lrt -ifeq ($(CONFIG_RTE_LIBRTE_TABLE),y) -LDLIBS += -lrte_table -endif - -ifeq ($(CONFIG_RTE_LIBRTE_PORT),y) -LDLIBS += -lrte_port -endif - -ifeq ($(CONFIG_RTE_LIBRTE_TIMER),y) -LDLIBS += -lrte_timer -endif - -ifeq ($(CONFIG_RTE_LIBRTE_HASH),y) -LDLIBS += -lrte_hash -endif - -ifeq ($(CONFIG_RTE_LIBRTE_JOBSTATS),y) -LDLIBS += -lrte_jobstats -endif - -ifeq ($(CONFIG_RTE_LIBRTE_LPM),y) -LDLIBS += -lrte_lpm -endif - -ifeq ($(CONFIG_RTE_LIBRTE_POWER),y) -LDLIBS += -lrte_power -endif - -ifeq ($(CONFIG_RTE_LIBRTE_ACL),y) -LDLIBS += -lrte_acl -endif - -ifeq ($(CONFIG_RTE_LIBRTE_METER),y) -LDLIBS += -lrte_meter -endif - -ifeq ($(CONFIG_RTE_LIBRTE_SCHED),y) -LDLIBS += -lrte_sched -LDLIBS += -lm -LDLIBS += -lrt -endif - -ifeq ($(CONFIG_RTE_LIBRTE_VHOST), y) -LDLIBS += -lrte_vhost -endif +LDLIBS-$(CONFIG_RTE_LIBRTE_VHOST) += -lrte_vhost endif # ! CONFIG_RTE_BUILD_COMBINE_LIBS -ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) -LDLIBS += -lpcap -endif +LDLIBS-
[dpdk-dev] Beyond DPDK 2.0
On Mon, Apr 27, 2015 at 08:46:01AM -0500, Jay Rolette wrote:
> On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman wrote:
>
> > On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> > > On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman
> > wrote:
> > >
> > > > So, I hear your arguments, and its understandable that you might not
> > want
> > > > a GPL
> > > > licensed product, given that the DPDK is a library (though I'm not sure
> > > > what the
> > > > aversion to LGPL would be). Regardless, I think this conversation is a
> > > > bit more
> > > > about participation than license choice. While you are correct, in
> > that
> > > > the
> > > > first step to support (by which I presume you mean participation in the
> > > > community) is use, the goal here is to get people contributing patches
> > and
> > > > helping increase the usefulness of DPDK.
> > >
> > >
> > > > Given that DPDK is primarily licensed as BSD now, whats preventing
> > you, or
> > > > what
> > > > would encourage you to participate in the community? I see emails from
> > > > infiniteio addresss in the archives asking questions and making
> > > > suggestions on
> > > > occasion, but no patches. What would get you (or others in a simmilar
> > > > situation) to submit those?
> > > >
> > >
> > > 36 hours in the day? :)
> > >
> > > It's not a lot, but we've submitted a couple of small patches. It's
> > mostly
> > > a matter of opportunity. We submit patches as we come across DPDK bugs or
> > > find useful optos.
> > >
> >
>
>
> >
> > Understand, I'm not trying to single you out here. I see that you, and
> > others
> > from infiniteio have had some participation in the project, and thats
> > great, and
> > appreciated. I'm more focused on why that level of participation is not
> > higher
> > (not only from you, but from the larger presumed user base in general). As
> > noted at the start of this thread, one of the goals of this discussion is
> > to
> > find ways to maximize participation in the project, and from you I'm
> > hearing
> > that:
> >
> > 1) you use the dpdk because it lowers maintenence overhead
> > 2) you don't participate more in the project because your product work
> > schedule
> > doesn't allow you to do so.
> >
> > Are those both accurate statements?
> >
>
> (1) was just my response to Luke about what would motivate a company to
> submit patches if the license didn't require it (GPL vs BSD discussion).
> Maint overhead had little to do with why we decided to use DPDK.
>
> (2) is certainly true enough, but not really all that big of a factor in
> the reasons why our participation isn't at some higher level. I'd say there
> are two primary factors:
>
> *New Contributors*
> Dropping a major patch on a project where we have no history would be
> foolish and frustrating. Every open source project has a vibe to it and its
> own way of operating. It normally takes some time to figure that out, but
> for major contributions, it generally involves a level of trust.
>
> Major code drops or patches aren't generally well received unless it is
> from someone that is known and trusted by the community. Building up that
> trust ("street cred") normally involves participating in smaller, less
> risky ways. Answering questions where you can, small patches to fix bugs,
> possibly reviewing code (although this can be iffy as well), etc.
>
> This facilitates understanding the process, who the players are and what
> sort of toes you are likely to step on.
>
> It also gives you time to ramp up on the internals of the code and
> philosophy/goals of the project better. With DPDK, performance is obviously
> more important than portability. Until recently, very little care was given
> to API stability or the impact that has on DPDK apps. Both of those are
> very different approaches than typical and it affects what you might do
> when approaching submitting a patch.
>
> If you want to build up the number of folks contributing, expect them to
> start small and make sure it actually GOES somewhere.
>
> The first patch I submitted in mid-December had some quick responses and
> questions back-and-forth, but then stalled on a couple of undocumented
> minor stylistic things (comment style and use of #ifdefs). I never heard
> anything back and 4.5 months later, a simple startup opto is still sitting
> there.
>
> The second patch I submitted (also mid-December) got no response at all for
> 4 months. I've replied to the feedback that came eventually, but once
> again, no subsequent answers.
>
> Neither of the patches were important, but the process doesn't exactly
> inspire a strong desire to contribute more.
>
> *Different Goals*
> I see at least two different sets of people on the mailing list. The heavy
> hitters generally have a product reason for their high level of involvement
> with DPDK. For Intel and 6Wind, the reasons are pretty obvious. Same deal
> with NIC vendors. For large companies, sometimes the reasons are less
> obvious, but s
[dpdk-dev] [PATCH] kni: fix compilation issue on kernel 4.0.0
Due to API changes in function pointer ndo_bridge_setlink
(commit ad41faa8) and the rename of functions vlan_tx_*
(commit df8a39de) in kernel 4.0, DPDK would not build.
This patch adds the properly checks to fix the compilation.
Reported-by: Stephen Hemminger
Signed-off-by: Pablo de Lara
---
lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c |6 ++
lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h |6 ++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
index 24b147d..bc3c6a3 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/igb_main.c
@@ -2198,8 +2198,14 @@ static int igb_ndo_fdb_dump(struct sk_buff *skb,
#endif /* USE_DEFAULT_FDB_DEL_DUMP */
#ifdef HAVE_BRIDGE_ATTRIBS
+#ifdef HAVE_NDO_BRIDGE_SET_DEL_LINK_FLAGS
+static int igb_ndo_bridge_setlink(struct net_device *dev,
+ struct nlmsghdr *nlh,
+ u16 flags)
+#else
static int igb_ndo_bridge_setlink(struct net_device *dev,
struct nlmsghdr *nlh)
+#endif /* HAVE_NDO_BRIDGE_SET_DEL_LINK_FLAGS */
{
struct igb_adapter *adapter = netdev_priv(dev);
struct e1000_hw *hw = &adapter->hw;
diff --git a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
index 2e7e714..54d1f86 100644
--- a/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
+++ b/lib/librte_eal/linuxapp/kni/ethtool/igb/kcompat.h
@@ -3885,4 +3885,10 @@ skb_set_hash(struct sk_buff *skb, __u32 hash,
__always_unused int type)
#define HAVE_NDO_FDB_ADD_VID
#endif /* >= 3.19.0 */
+#if ( LINUX_VERSION_CODE >= KERNEL_VERSION(4,0,0) )
+/* vlan_tx_xx functions got renamed to skb_vlan */
+#define vlan_tx_tag_get skb_vlan_tag_get
+#define vlan_tx_tag_present skb_vlan_tag_present
+#define HAVE_NDO_BRIDGE_SET_DEL_LINK_FLAGS
+#endif /* 4.0.0 */
#endif /* _KCOMPAT_H_ */
--
1.7.4.1
[dpdk-dev] [PATCH v1 3/4] ixgbe: Kill ixgbe_recv_scattered_pkts()
Hi Vlad,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vlad Zolotarov
> Sent: Sunday, April 26, 2015 3:46 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v1 3/4] ixgbe: Kill ixgbe_recv_scattered_pkts()
>
> Kill ixgbe_recv_scattered_pkts() - use ixgbe_recv_pkts_lro_single_alloc()
> instead.
>
> Work against HW queues in LRO and scattered Rx cases is exactly the same.
> Therefore we may drop the inferior callback.
>
> Signed-off-by: Vlad Zolotarov
> ---
> lib/librte_pmd_ixgbe/ixgbe_ethdev.c | 2 +-
> lib/librte_pmd_ixgbe/ixgbe_ethdev.h | 3 -
> lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 243
> +---
> 3 files changed, 7 insertions(+), 241 deletions(-)
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> index aec1de9..5f9a1cf 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.c
> @@ -986,7 +986,7 @@ eth_ixgbevf_dev_init(struct rte_eth_dev *eth_dev)
>* RX function */
> if (rte_eal_process_type() != RTE_PROC_PRIMARY){
> if (eth_dev->data->scattered_rx)
> - eth_dev->rx_pkt_burst = ixgbe_recv_scattered_pkts;
> + eth_dev->rx_pkt_burst =
> ixgbe_recv_pkts_lro_single_alloc;
> return 0;
> }
>
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
> b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
> index 5b90115..419ea5d 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
> +++ b/lib/librte_pmd_ixgbe/ixgbe_ethdev.h
> @@ -352,9 +352,6 @@ void ixgbevf_dev_rxtx_start(struct rte_eth_dev *dev);
> uint16_t ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
> uint16_t nb_pkts);
>
> -uint16_t ixgbe_recv_scattered_pkts(void *rx_queue,
> - struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
> -
> uint16_t ixgbe_recv_pkts_lro_single_alloc(void *rx_queue,
> struct rte_mbuf **rx_pkts, uint16_t nb_pkts);
> uint16_t ixgbe_recv_pkts_lro_bulk_alloc(void *rx_queue,
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> index a45f51e..c23e20f 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx.c
> @@ -1722,239 +1722,6 @@ ixgbe_recv_pkts_lro_bulk_alloc(void *rx_queue, struct
> rte_mbuf **rx_pkts,
> return ixgbe_recv_pkts_lro(rx_queue, rx_pkts, nb_pkts, true);
> }
>
> -uint16_t
> -ixgbe_recv_scattered_pkts(void *rx_queue, struct rte_mbuf **rx_pkts,
> - uint16_t nb_pkts)
> -{
> - struct ixgbe_rx_queue *rxq;
> - volatile union ixgbe_adv_rx_desc *rx_ring;
> - volatile union ixgbe_adv_rx_desc *rxdp;
> - struct ixgbe_rx_entry *sw_ring;
> - struct ixgbe_rx_entry *rxe;
> - struct rte_mbuf *first_seg;
> - struct rte_mbuf *last_seg;
> - struct rte_mbuf *rxm;
> - struct rte_mbuf *nmb;
> - union ixgbe_adv_rx_desc rxd;
> - uint64_t dma; /* Physical address of mbuf data buffer */
> - uint32_t staterr;
> - uint16_t rx_id;
> - uint16_t nb_rx;
> - uint16_t nb_hold;
> - uint16_t data_len;
> -
> - nb_rx = 0;
> - nb_hold = 0;
> - rxq = rx_queue;
> - rx_id = rxq->rx_tail;
> - rx_ring = rxq->rx_ring;
> - sw_ring = rxq->sw_ring;
> -
> - /*
> - * Retrieve RX context of current packet, if any.
> - */
> - first_seg = rxq->pkt_first_seg;
> - last_seg = rxq->pkt_last_seg;
> -
> - while (nb_rx < nb_pkts) {
> - next_desc:
> - /*
> - * The order of operations here is important as the DD status
> - * bit must not be read after any other descriptor fields.
> - * rx_ring and rxdp are pointing to volatile data so the order
> - * of accesses cannot be reordered by the compiler. If they were
> - * not volatile, they could be reordered which could lead to
> - * using invalid descriptor fields when read from rxd.
> - */
> - rxdp = &rx_ring[rx_id];
> - staterr = rxdp->wb.upper.status_error;
> - if (! (staterr & rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD)))
> - break;
> - rxd = *rxdp;
> -
> - /*
> - * Descriptor done.
> - *
> - * Allocate a new mbuf to replenish the RX ring descriptor.
> - * If the allocation fails:
> - *- arrange for that RX descriptor to be the first one
> - * being parsed the next time the receive function is
> - * invoked [on the same queue].
> - *
> - *- Stop parsing the RX ring and return immediately.
> - *
> - * This policy does not drop the packet received in the RX
> - * descriptor for which the allocation of a new mbuf failed.
> - * Thus, it allows that packet to be later retrieved if
> -
[dpdk-dev] Beyond DPDK 2.0
On Fri, 24 Apr 2015 09:47:58 +0200 Luke Gorrie wrote: > Hi Tim, > > On 16 April 2015 at 12:38, O'Driscoll, Tim > wrote: > > > Following the launch of DPDK by Intel as an internal development project, > > the launch of dpdk.org by 6WIND in 2013, and the first DPDK RPM packages > > for Fedora in 2014, 6WIND, Red Hat and Intel would like to prepare for > > future releases after DPDK 2.0 by starting a discussion on its evolution. > > Anyone is welcome to join this initiative. > > > > Thank you for the open invitation. > > I have a couple of questions about the long term of DPDK: > > 1. How will DPDK manage overlap with other project over time? > In general DPDK will be successful only if it stick to differentiating technology and avoids NIH and reinvention. I.e if DPDK tries to redo things in libc or have special needs, then DPDK becomes harder to use for many things and makes DPDK applications hard to integrate with other libraries. It is bad enough now that each library has its own view of threads. > DPDK into the kernel than the rest of the good bits of the kernel into DPDK? If DPDK tries to become too general it will lose the performance advantage. The kernel has to serve all types of applications, and have many layers of services therefore it is slow. For example, if every DPDK facility had its own locking and was thread safe the performance would end up being about the same as just using kernel. > 2. How will DPDK users justify contributing to DPDK upstream? > > Engineers in network equipment vendors want to contribute to open source, > but what is the incentive for the companies to support this? This would be > easy if DPDK were GPL'd (they are compelled) or if everybody were > dynamically linking with the upstream libdpdk (can't have private patches). > However, in a world where DPDK is BSD-licensed and statically linked, is it > not both cheaper and competitively advantageous to keep fixes and > optimizations in house? There are several incentives. a. Brocade views open source as a differentiator from competitors and wants to contribute as much as possible to open source, this includes DPDK, Open Daylight and Openstack. Marketing benefit. b. By contributing what we do back we get benefits of more testing and review. Several bugs have been spotted in areas that were not covered because the current product usage and testing will not cover all possibilities. c. By contributing back, the contributor gets to set the agenda and make the API's. If you go first, you set the API and you can make life hard for competitors or other users who do the same thing but haven't contributed. In fact, the worst pain for us was cases where there were two or more parallel implementations of something to deal with (ie vmxnet3). "Lead, follow, or get of the way"
[dpdk-dev] [PATCH v7 1/6] Move common functions in eal_thread.c
On Mon, Apr 27, 2015 at 03:39:41PM -0700, Ravi Kerur wrote: > On Mon, Apr 27, 2015 at 6:44 AM, Neil Horman wrote: > > > On Sat, Apr 25, 2015 at 05:09:01PM -0700, Ravi Kerur wrote: > > > On Sat, Apr 25, 2015 at 6:02 AM, Neil Horman > > wrote: > > > > > > > On Sat, Apr 25, 2015 at 08:32:42AM -0400, Neil Horman wrote: > > > > > On Fri, Apr 24, 2015 at 06:45:06PM -0700, Ravi Kerur wrote: > > > > > > On Fri, Apr 24, 2015 at 2:24 PM, Ravi Kerur > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 24, 2015 at 12:51 PM, Neil Horman < > > nhorman at tuxdriver.com > > > > > > > > > > > > wrote: > > > > > > > > > > > > > >> On Fri, Apr 24, 2015 at 12:21:23PM -0700, Ravi Kerur wrote: > > > > > > >> > On Fri, Apr 24, 2015 at 11:53 AM, Neil Horman < > > > > nhorman at tuxdriver.com> > > > > > > >> wrote: > > > > > > >> > > > > > > > >> > > On Fri, Apr 24, 2015 at 09:45:24AM -0700, Ravi Kerur wrote: > > > > > > >> > > > On Fri, Apr 24, 2015 at 8:22 AM, Neil Horman < > > > > nhorman at tuxdriver.com > > > > > > >> > > > > > > > >> > > wrote: > > > > > > >> > > > > > > > > > >> > > > > On Fri, Apr 24, 2015 at 08:14:04AM -0700, Ravi Kerur > > wrote: > > > > > > >> > > > > > On Fri, Apr 24, 2015 at 6:51 AM, Neil Horman < > > > > > > >> nhorman at tuxdriver.com> > > > > > > >> > > > > wrote: > > > > > > >> > > > > > > > > > > > >> > > > > > > On Thu, Apr 23, 2015 at 02:35:31PM -0700, Ravi Kerur > > > > wrote: > > > > > > >> > > > > > > > Changes in v7 > > > > > > >> > > > > > > > Remove _setname_ pthread calls. > > > > > > >> > > > > > > > Use rte_gettid() API in RTE_LOG to print > > thread_id. > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v6 > > > > > > >> > > > > > > > Remove RTE_EXEC_ENV_BSDAPP from > > eal_common_thread.c > > > > file. > > > > > > >> > > > > > > > Add pthread_setname_np/pthread_set_name_np for > > > > Linux/FreeBSD > > > > > > >> > > > > > > > respectively. Plan to use _getname_ in RTE_LOG > > when > > > > > > >> available. > > > > > > >> > > > > > > > Use existing rte_get_systid() in RTE_LOG to print > > > > thread_id. > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v5 > > > > > > >> > > > > > > > Rebase to latest code. > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v4 > > > > > > >> > > > > > > > None > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v3 > > > > > > >> > > > > > > > Changed subject to be more explicit on file name > > > > inclusion. > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v2 > > > > > > >> > > > > > > > None > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Changes in v1 > > > > > > >> > > > > > > > eal_thread.c has minor differences between Linux > > and > > > > BSD, > > > > > > >> move > > > > > > >> > > > > > > > entire file into common directory. > > > > > > >> > > > > > > > Use RTE_EXEC_ENV_BSDAPP to differentiate on minor > > > > > > >> differences. > > > > > > >> > > > > > > > Rename eal_thread.c to eal_common_thread.c > > > > > > >> > > > > > > > Makefile changes to reflect file move and name > > change. > > > > > > >> > > > > > > > Fix checkpatch warnings. > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > Signed-off-by: Ravi Kerur > > > > > > >> > > > > > > > --- > > > > > > >> > > > > > > > lib/librte_eal/bsdapp/eal/Makefile| 2 > > +- > > > > > > >> > > > > > > > lib/librte_eal/bsdapp/eal/eal_thread.c| 152 > > > > > > >> > > > > > > -- > > > > > > >> > > > > > > > lib/librte_eal/common/eal_common_thread.c | 147 > > > > > > >> > > > > > > - > > > > > > >> > > > > > > > lib/librte_eal/linuxapp/eal/eal_thread.c | 152 > > > > > > >> > > > > > > +- > > > > > > >> > > > > > > > 4 files changed, 148 insertions(+), 305 > > deletions(-) > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > diff --git a/lib/librte_eal/bsdapp/eal/Makefile > > > > > > >> > > > > > > b/lib/librte_eal/bsdapp/eal/Makefile > > > > > > >> > > > > > > > index 2357cfa..55971b9 100644 > > > > > > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/Makefile > > > > > > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/Makefile > > > > > > >> > > > > > > > @@ -87,7 +87,7 @@ CFLAGS_eal_common_log.o := > > > > -D_GNU_SOURCE > > > > > > >> > > > > > > > # workaround for a gcc bug with noreturn > > attribute > > > > > > >> > > > > > > > # > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 > > > > > > >> > > > > > > > ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) > > > > > > >> > > > > > > > -CFLAGS_eal_thread.o += -Wno-return-type > > > > > > >> > > > > > > > +CFLAGS_eal_common_thread.o += -Wno-return-type > > > > > > >> > > > > > > > CFLAGS_eal_hpet.o += -Wno-return-type > > > > > > >> > > > > > > > endif > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > diff --git > > a/lib/librte_eal/bsdapp/eal/eal_thread.c > > > > > > >> > > > > > > b/lib/librte_eal/b
[dpdk-dev] Beyond DPDK 2.0
On Tue, Apr 28, 2015 at 12:26 PM, Neil Horman wrote:
> On Mon, Apr 27, 2015 at 08:46:01AM -0500, Jay Rolette wrote:
> > On Sat, Apr 25, 2015 at 7:10 AM, Neil Horman
> wrote:
> >
> > > On Fri, Apr 24, 2015 at 02:55:33PM -0500, Jay Rolette wrote:
> > > > On Fri, Apr 24, 2015 at 1:51 PM, Neil Horman
> > > wrote:
> > > >
> > > > > So, I hear your arguments, and its understandable that you might
> not
> > > want
> > > > > a GPL
> > > > > licensed product, given that the DPDK is a library (though I'm not
> sure
> > > > > what the
> > > > > aversion to LGPL would be). Regardless, I think this conversation
> is a
> > > > > bit more
> > > > > about participation than license choice. While you are correct, in
> > > that
> > > > > the
> > > > > first step to support (by which I presume you mean participation
> in the
> > > > > community) is use, the goal here is to get people contributing
> patches
> > > and
> > > > > helping increase the usefulness of DPDK.
> > > >
> > > >
> > > > > Given that DPDK is primarily licensed as BSD now, whats preventing
> > > you, or
> > > > > what
> > > > > would encourage you to participate in the community? I see emails
> from
> > > > > infiniteio addresss in the archives asking questions and making
> > > > > suggestions on
> > > > > occasion, but no patches. What would get you (or others in a
> simmilar
> > > > > situation) to submit those?
> > > > >
> > > >
> > > > 36 hours in the day? :)
> > > >
> > > > It's not a lot, but we've submitted a couple of small patches. It's
> > > mostly
> > > > a matter of opportunity. We submit patches as we come across DPDK
> bugs or
> > > > find useful optos.
> > > >
> > >
> >
> >
> > >
> > > Understand, I'm not trying to single you out here. I see that you, and
> > > others
> > > from infiniteio have had some participation in the project, and thats
> > > great, and
> > > appreciated. I'm more focused on why that level of participation is not
> > > higher
> > > (not only from you, but from the larger presumed user base in
> general). As
> > > noted at the start of this thread, one of the goals of this discussion
> is
> > > to
> > > find ways to maximize participation in the project, and from you I'm
> > > hearing
> > > that:
> > >
> > > 1) you use the dpdk because it lowers maintenence overhead
> > > 2) you don't participate more in the project because your product work
> > > schedule
> > > doesn't allow you to do so.
> > >
> > > Are those both accurate statements?
> > >
> >
> > (1) was just my response to Luke about what would motivate a company to
> > submit patches if the license didn't require it (GPL vs BSD discussion).
> > Maint overhead had little to do with why we decided to use DPDK.
> >
> > (2) is certainly true enough, but not really all that big of a factor in
> > the reasons why our participation isn't at some higher level. I'd say
> there
> > are two primary factors:
> >
> > *New Contributors*
> > Dropping a major patch on a project where we have no history would be
> > foolish and frustrating. Every open source project has a vibe to it and
> its
> > own way of operating. It normally takes some time to figure that out, but
> > for major contributions, it generally involves a level of trust.
> >
> > Major code drops or patches aren't generally well received unless it is
> > from someone that is known and trusted by the community. Building up that
> > trust ("street cred") normally involves participating in smaller, less
> > risky ways. Answering questions where you can, small patches to fix bugs,
> > possibly reviewing code (although this can be iffy as well), etc.
> >
> > This facilitates understanding the process, who the players are and what
> > sort of toes you are likely to step on.
> >
> > It also gives you time to ramp up on the internals of the code and
> > philosophy/goals of the project better. With DPDK, performance is
> obviously
> > more important than portability. Until recently, very little care was
> given
> > to API stability or the impact that has on DPDK apps. Both of those are
> > very different approaches than typical and it affects what you might do
> > when approaching submitting a patch.
> >
> > If you want to build up the number of folks contributing, expect them to
> > start small and make sure it actually GOES somewhere.
> >
> > The first patch I submitted in mid-December had some quick responses and
> > questions back-and-forth, but then stalled on a couple of undocumented
> > minor stylistic things (comment style and use of #ifdefs). I never heard
> > anything back and 4.5 months later, a simple startup opto is still
> sitting
> > there.
> >
> > The second patch I submitted (also mid-December) got no response at all
> for
> > 4 months. I've replied to the feedback that came eventually, but once
> > again, no subsequent answers.
> >
> > Neither of the patches were important, but the process doesn't exactly
> > inspire a strong desire to contribute more.
> >
> > *Different Goals*
> > I see at least
[dpdk-dev] Issues of MSIx interrupt enable with user space driver
Hi All, We are porting driver from kernel into user space driver with DPDK for one of our devices. Polling thread works fine without any issue. However, we want to switch from polling to interrupt based handler. While we enable interrupt with VFIO MSIx, we always get below errors after issuing one command: [ 465.464186] dmar: DRHD: handling fault status reg 2 [ 465.464194] dmar: INTR-REMAP: Request device [[02:00.0] fault index 27 [ 465.464194] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear Here are steps we follow to enable interrupt: 1. --vfio-intr msix was passed in as parameter for rte_eal_init 2. rte_intr_enable was called during the drive probe stage. 3. rte_intr_callback_register was called after interrupt was enabled Is there anyone in the forum who worked on the interrupt handler to share with us about your comments? thanks for your help in advance. Regards, James
[dpdk-dev] Issues of MSIx interrupt enable with user space driver
The V6 "Interrupt PMD" patch has been sent out to DPDK.org 2 months ago, and V7 is under development with changes to include more generic APIs that could support all kinds of interrupts (e.g. HW Rx interrupt and SW ring interrupt). Stay tuned. > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of James (Fei) Liu-SSI > Sent: Wednesday, April 29, 2015 5:58 AM > To: dev at dpdk.org > Subject: [dpdk-dev] Issues of MSIx interrupt enable with user space driver > > Hi All, > We are porting driver from kernel into user space driver with DPDK for > one of our devices. Polling thread works fine without > any issue. However, we want to switch from polling to interrupt based > handler. While we enable interrupt with VFIO MSIx, we > always get below errors after issuing one command: > > [ 465.464186] dmar: DRHD: handling fault status reg 2 > [ 465.464194] dmar: INTR-REMAP: Request device [[02:00.0] fault index 27 > [ 465.464194] INTR-REMAP:[fault reason 34] Present field in the IRTE entry > is clear > > Here are steps we follow to enable interrupt: > 1. --vfio-intr msix was passed in as parameter for rte_eal_init > 2. rte_intr_enable was called during the drive probe stage. > 3. rte_intr_callback_register was called after interrupt was enabled > > > > Is there anyone in the forum who worked on the interrupt handler to share > with us about your comments? thanks for your help > in advance. > > Regards, > James >
[dpdk-dev] Issues of MSIx interrupt enable with user space driver
On Tue, 28 Apr 2015 21:57:31 + "James (Fei) Liu-SSI" wrote: > Hi All, > We are porting driver from kernel into user space driver with DPDK for > one of our devices. Polling thread works fine without any issue. However, we > want to switch from polling to interrupt based handler. While we enable > interrupt with VFIO MSIx, we always get below errors after issuing one > command: > > [ 465.464186] dmar: DRHD: handling fault status reg 2 > [ 465.464194] dmar: INTR-REMAP: Request device [[02:00.0] fault index 27 > [ 465.464194] INTR-REMAP:[fault reason 34] Present field in the IRTE entry > is clear > > Here are steps we follow to enable interrupt: > 1. --vfio-intr msix was passed in as parameter for rte_eal_init > 2. rte_intr_enable was called during the drive probe stage. > 3. rte_intr_callback_register was called after interrupt was enabled > > > > Is there anyone in the forum who worked on the interrupt handler to share > with us about your comments? thanks for your help in advance. Do you have kernel version in your build environment that has ? Do you have iommu enabled on your target machine? Did you program the MSI-X correctly?
[dpdk-dev] running l2fwd-ivshmem
hello, has anyone out there successfully run the l2fwd-ivshmem example successfully between 2 kvms, and got some notes or instructions to share? I see I'm not the first one to struggle with this: http://dpdk.org/ml/archives/dev/2014-June/003556.html but memnic-pmd doesnt build with the latest kernels either, http://www.litchfie.dpdk.org/ml/archives/dev/2015-April/016500.html Examples accompanied by READMEs would be a good idea :-) Any help is appreciated, including redirects to other groups where I may find the answers to the questions above. Thanks Sowmini
[dpdk-dev] Issues of MSIx interrupt enable with user space driver
Hi ALL, Dump trace was added for more debugging information. thanks for your help in advance. [ 180.360229] vfio_ecap_init: :02:00.0 hiding ecap 0x19 at 0x180 [ 180.486813] vfio-pci :02:00.0: irq 27 for MSI/MSI-X [ 180.489332] dmar: DRHD: handling fault status reg 2 [ 180.489354] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE 3.17.2 #4 [ 180.489356] Hardware name: Dell Inc. OptiPlex 7010/0773VG, BIOS A05 07/31/2012 [ 180.489358] 001f 88011e203e68 81ac42d7 [ 180.489362] 88011e203ec8 81997161 0019 88011d807780 [ 180.489365] 0200 0022 88011d80692c 880117a80800 [ 180.489368] Call Trace: [ 180.489370][] dump_stack+0x45/0x56 [ 180.489383] [] dmar_fault+0xc1/0x230 [ 180.489388] [] handle_irq_event_percpu+0x3e/0x1a0 [ 180.489391] [] handle_irq_event+0x3d/0x60 [ 180.489394] [] handle_edge_irq+0x77/0x130 [ 180.489399] [] handle_irq+0x1e/0x30 [ 180.489402] [] do_IRQ+0x4f/0xf0 [ 180.489406] [] common_interrupt+0x6d/0x6d [ 180.489407][] ? cpuidle_enter_state+0x70/0x170 [ 180.489415] [] ? cpuidle_enter_state+0x5d/0x170 [ 180.489419] [] cpuidle_enter+0x17/0x20 [ 180.489422] [] cpu_startup_entry+0x31d/0x340 [ 180.489425] [] rest_init+0x77/0x80 [ 180.489430] [] start_kernel+0x42a/0x435 [ 180.489433] [] ? set_init_arg+0x53/0x53 [ 180.489437] [] ? early_idt_handlers+0x120/0x120 [ 180.489440] [] x86_64_start_reservations+0x2a/0x2c [ 180.489443] [] x86_64_start_kernel+0x143/0x152 [ 180.489446] dmar: INTR-REMAP: Request device [[02:00.0] fault index 1f [ 180.489446] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear Regards, James From: dev [dev-bounces at dpdk.org] on behalf of James (Fei) Liu-SSI [james@ssi.samsung.com] Sent: Tuesday, April 28, 2015 2:57 PM To: dev at dpdk.org Subject: [dpdk-dev] Issues of MSIx interrupt enable with user space driver Hi All, We are porting driver from kernel into user space driver with DPDK for one of our devices. Polling thread works fine without any issue. However, we want to switch from polling to interrupt based handler. While we enable interrupt with VFIO MSIx, we always get below errors after issuing one command: [ 465.464186] dmar: DRHD: handling fault status reg 2 [ 465.464194] dmar: INTR-REMAP: Request device [[02:00.0] fault index 27 [ 465.464194] INTR-REMAP:[fault reason 34] Present field in the IRTE entry is clear Here are steps we follow to enable interrupt: 1. --vfio-intr msix was passed in as parameter for rte_eal_init 2. rte_intr_enable was called during the drive probe stage. 3. rte_intr_callback_register was called after interrupt was enabled Is there anyone in the forum who worked on the interrupt handler to share with us about your comments? thanks for your help in advance. Regards, James
[dpdk-dev] [PATCH v8 0/6] Move common functions in EAL
Changes in v8 includes Re-ordering source file compilation to fix ABI warning. Ran validate-abi against x86_64-native-linuxapp-gcc, x86_64-native-linuxapp-clang and x86_64-ivshmem-linuxapp-gcc environments. Testing: Linux - Ubuntu x86_64 14.04 Compilation successful (x86_64-native-linuxapp-gcc and x86_64-native-linuxapp-clang). "make test" results match baseline code. testpmd utility on I217/I218 Intel chipset. FreeBSD 10.0 x86_64 Compilation successful (x86_64-native-bsdapp-gcc and x86_64-native-bsdapp-clang). Tested with helloworld, timer and cmdline examples. Ravi Kerur (6): Move common functions in eal_thread.c Move common functions in eal.c Move common functions in eal_lcore.c Move common functions in eal_timer.c Move common functions in eal_memory.c Move common functions in eal_pci.c lib/librte_eal/bsdapp/eal/Makefile | 9 +- lib/librte_eal/bsdapp/eal/eal.c | 271 +++- lib/librte_eal/bsdapp/eal/eal_lcore.c| 72 ++- lib/librte_eal/bsdapp/eal/eal_memory.c | 47 ++--- lib/librte_eal/bsdapp/eal/eal_pci.c | 72 +-- lib/librte_eal/bsdapp/eal/eal_thread.c | 152 -- lib/librte_eal/bsdapp/eal/eal_timer.c| 52 + lib/librte_eal/common/eal_common_app_usage.c | 63 ++ lib/librte_eal/common/eal_common_lcore.c | 107 ++ lib/librte_eal/common/eal_common_mem_cfg.c | 224 lib/librte_eal/common/eal_common_memory.c| 38 +++- lib/librte_eal/common/eal_common_pci.c | 72 +++ lib/librte_eal/common/eal_common_proc_type.c | 58 ++ lib/librte_eal/common/eal_common_sysfs.c | 148 ++ lib/librte_eal/common/eal_common_thread.c| 147 - lib/librte_eal/common/eal_common_timer.c | 102 + lib/librte_eal/common/eal_hugepages.h| 1 + lib/librte_eal/common/eal_private.h | 171 +++- lib/librte_eal/common/include/rte_eal.h | 4 + lib/librte_eal/linuxapp/eal/Makefile | 10 +- lib/librte_eal/linuxapp/eal/eal.c| 296 --- lib/librte_eal/linuxapp/eal/eal_lcore.c | 66 +- lib/librte_eal/linuxapp/eal/eal_memory.c | 36 +--- lib/librte_eal/linuxapp/eal/eal_pci.c| 75 +-- lib/librte_eal/linuxapp/eal/eal_thread.c | 152 +- lib/librte_eal/linuxapp/eal/eal_timer.c | 55 + 26 files changed, 1277 insertions(+), 1223 deletions(-) create mode 100644 lib/librte_eal/common/eal_common_app_usage.c create mode 100644 lib/librte_eal/common/eal_common_lcore.c create mode 100644 lib/librte_eal/common/eal_common_mem_cfg.c create mode 100644 lib/librte_eal/common/eal_common_proc_type.c create mode 100644 lib/librte_eal/common/eal_common_sysfs.c create mode 100644 lib/librte_eal/common/eal_common_timer.c -- 1.9.1
[dpdk-dev] [PATCH v8 1/6] Move common functions in eal_thread.c
Changes in v8
Fixed ABI warnings by reordering compilation of
eal_common_thread.c.
Changes in v7
Remove _setname_ pthread calls.
Use rte_gettid() API in RTE_LOG to print thread_id.
Changes in v6
Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c file.
Add pthread_setname_np/pthread_set_name_np for Linux/FreeBSD
respectively. Plan to use _getname_ in RTE_LOG when available.
Use existing rte_get_systid() in RTE_LOG to print thread_id.
Changes in v5
Rebase to latest code.
Changes in v4
None
Changes in v3
Changed subject to be more explicit on file name inclusion.
Changes in v2
None
Changes in v1
eal_thread.c has minor differences between Linux and BSD, move
entire file into common directory.
Use RTE_EXEC_ENV_BSDAPP to differentiate on minor differences.
Rename eal_thread.c to eal_common_thread.c
Makefile changes to reflect file move and name change.
Fix checkpatch warnings.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/Makefile| 3 +-
lib/librte_eal/bsdapp/eal/eal_thread.c| 152 --
lib/librte_eal/common/eal_common_thread.c | 147 -
lib/librte_eal/linuxapp/eal/Makefile | 3 +-
lib/librte_eal/linuxapp/eal/eal_thread.c | 152 +-
5 files changed, 151 insertions(+), 306 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 2357cfa..b7ca47c 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -55,6 +55,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_hugepage_info.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_thread.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
@@ -77,7 +78,6 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_hexdump.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_devargs.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_dev.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_options.c
-SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_thread.c
CFLAGS_eal.o := -D_GNU_SOURCE
#CFLAGS_eal_thread.o := -D_GNU_SOURCE
@@ -88,6 +88,7 @@ CFLAGS_eal_common_log.o := -D_GNU_SOURCE
# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603
ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y)
CFLAGS_eal_thread.o += -Wno-return-type
+CFLAGS_eal_common_thread.o += -Wno-return-type
CFLAGS_eal_hpet.o += -Wno-return-type
endif
diff --git a/lib/librte_eal/bsdapp/eal/eal_thread.c
b/lib/librte_eal/bsdapp/eal/eal_thread.c
index 9a03437..5714b8f 100644
--- a/lib/librte_eal/bsdapp/eal/eal_thread.c
+++ b/lib/librte_eal/bsdapp/eal/eal_thread.c
@@ -35,163 +35,11 @@
#include
#include
#include
-#include
-#include
-#include
-#include
#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
#include "eal_private.h"
#include "eal_thread.h"
-RTE_DEFINE_PER_LCORE(unsigned, _lcore_id) = LCORE_ID_ANY;
-RTE_DEFINE_PER_LCORE(unsigned, _socket_id) = (unsigned)SOCKET_ID_ANY;
-RTE_DEFINE_PER_LCORE(rte_cpuset_t, _cpuset);
-
-/*
- * Send a message to a slave lcore identified by slave_id to call a
- * function f with argument arg. Once the execution is done, the
- * remote lcore switch in FINISHED state.
- */
-int
-rte_eal_remote_launch(int (*f)(void *), void *arg, unsigned slave_id)
-{
- int n;
- char c = 0;
- int m2s = lcore_config[slave_id].pipe_master2slave[1];
- int s2m = lcore_config[slave_id].pipe_slave2master[0];
-
- if (lcore_config[slave_id].state != WAIT)
- return -EBUSY;
-
- lcore_config[slave_id].f = f;
- lcore_config[slave_id].arg = arg;
-
- /* send message */
- n = 0;
- while (n == 0 || (n < 0 && errno == EINTR))
- n = write(m2s, &c, 1);
- if (n < 0)
- rte_panic("cannot write on configuration pipe\n");
-
- /* wait ack */
- do {
- n = read(s2m, &c, 1);
- } while (n < 0 && errno == EINTR);
-
- if (n <= 0)
- rte_panic("cannot read on configuration pipe\n");
-
- return 0;
-}
-
-/* set affinity for current thread */
-static int
-eal_thread_set_affinity(void)
-{
- unsigned lcore_id = rte_lcore_id();
-
- /* acquire system unique id */
- rte_gettid();
-
- /* update EAL thread core affinity */
- return rte_thread_set_affinity(&lcore_config[lcore_id].cpuset);
-}
-
-void eal_thread_init_master(unsigned lcore_id)
-{
- /* set the lcore ID in per-lcore memory area */
- RTE_PER_LCORE(_lcore_id) = lcore_id;
-
- /* set CPU affinity */
- if (eal_thread_set_affinity() < 0)
- rte_panic("cannot set affinity\n");
-}
-
-/* main loop of threads */
-__attrib
[dpdk-dev] [PATCH v8 2/6] Move common functions in eal.c
Changes in v8
Fix ABI warnings by reordering compilation of
eal_common_sysfs.c
eal_common_mem_cfg.c
eal_common_proc_type.c
eal_common_app_usage.c
Changes in v7
Fix compilation errors in clang.
Changes in v6
Split eal_common_system.c and eal_common_runtime.c into
eal_common_sysfs.c
eal_common_mem_cfg.c
eal_common_proc_type.c
eal_common_app_usage.c
based on functionality.
Changes in v5
Rebase to latest code.
Changes in v4
Remove eal_externs.h file, instead use _get_ and _set_ APIS
to access those variables.
Split eal_common.c into eal_common_system.c and
and eal_common_runtime.c
rte_eal prefix functions are moved to _runtime_ and
eal prefix functions are moved to _system_ files respectively.
Changes in v3
Changed subject to be more explicit on file name inclusion.
Changes in v2
In function rte_eal_config_create remove #ifdef _BSDAPP_
and initialize mem_cfg_addr unconditionally.
Changes in v1
Move common functions in eal.c to librte_eal/common/eal_common.c.
Following functions are moved to eal_common.c file.
struct rte_config *rte_eal_get_configuration(void);
int eal_parse_sysfs_value(const char *filename, unsigned long *val);
static void rte_eal_config_create(void);
enum rte_proc_type_t eal_proc_type_detect(void);
void rte_eal_config_init(void);
rte_usage_hook_t rte_set_application_usage_hook(rte_usage_hook_t
usage_func);
inline size_t eal_get_hugepage_mem_size(void);
void eal_check_mem_on_local_socket(void);
int sync_func(__attribute__((unused)) void *arg);
inline void rte_eal_mcfg_complete(void);
int rte_eal_has_hugepages(void);
enum rte_lcore_role_t rte_eal_lcore_role(unsigned lcore_id);
enum rte_proc_type_t rte_eal_process_type(void);
Makefile changes to reflect new files added.
Fix checkpatch warnings and errors.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/Makefile | 4 +
lib/librte_eal/bsdapp/eal/eal.c | 271 +++-
lib/librte_eal/common/eal_common_app_usage.c | 63 ++
lib/librte_eal/common/eal_common_mem_cfg.c | 224
lib/librte_eal/common/eal_common_proc_type.c | 58 ++
lib/librte_eal/common/eal_common_sysfs.c | 148 ++
lib/librte_eal/common/eal_hugepages.h| 1 +
lib/librte_eal/common/eal_private.h | 78 +++
lib/librte_eal/common/include/rte_eal.h | 4 +
lib/librte_eal/linuxapp/eal/Makefile | 4 +
lib/librte_eal/linuxapp/eal/eal.c| 296 ---
11 files changed, 660 insertions(+), 491 deletions(-)
create mode 100644 lib/librte_eal/common/eal_common_app_usage.c
create mode 100644 lib/librte_eal/common/eal_common_mem_cfg.c
create mode 100644 lib/librte_eal/common/eal_common_proc_type.c
create mode 100644 lib/librte_eal/common/eal_common_sysfs.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index b7ca47c..67abc54 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -52,6 +52,10 @@ LIBABIVER := 1
# specific to linuxapp exec-env
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) := eal.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_sysfs.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_mem_cfg.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_proc_type.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_app_usage.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_memory.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_hugepage_info.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_thread.c
diff --git a/lib/librte_eal/bsdapp/eal/eal.c b/lib/librte_eal/bsdapp/eal/eal.c
index 43e8a47..a9b1f38 100644
--- a/lib/librte_eal/bsdapp/eal/eal.c
+++ b/lib/librte_eal/bsdapp/eal/eal.c
@@ -80,29 +80,6 @@
#include "eal_hugepages.h"
#include "eal_options.h"
-#define MEMSIZE_IF_NO_HUGE_PAGE (64ULL * 1024ULL * 1024ULL)
-
-/* Allow the application to print its usage message too if set */
-static rte_usage_hook_trte_application_usage_hook = NULL;
-/* early configuration structure, when memory config is not mmapped */
-static struct rte_mem_config early_mem_config;
-
-/* define fd variable here, because file needs to be kept open for the
- * duration of the program, as we hold a write lock on it in the primary proc
*/
-static int mem_cfg_fd = -1;
-
-static struct flock wr_lock = {
- .l_type = F_WRLCK,
- .l_whence = SEEK_SET,
- .l_start = offsetof(struct rte_mem_config, memseg),
- .l_len = sizeof(early_mem_config.memseg),
-};
-
-/* Address of global and public configuration */
-static struct rte_config rte_config = {
- .mem_config = &early_mem_config,
-};
-
/* internal configuration (per-core) */
struct lcore_config lcore_config[RTE_MAX_LCORE];
@@ -112,160 +89,57 @@ struct internal_config internal_config;
/* used by rte_rdtsc() */
int rte_cycles_vmware_tsc_map;
-/* Return a pointer to the configuration structure */
-struct rte_config *
-rte_eal_get_configuration(void)
-{
-
[dpdk-dev] [PATCH v8 3/6] Move common functions in eal_lcore.c
Changes in v8
Reorder eal_common_lcore.c compilation.
Changes in v7
None
Changes in v6
None
Changes in v5
Rebase to latest code.
Changes in v4
Implement cpu_detected() for BSD.
Have common RTE_LOG for Linux and BSD in rte_eal_cpu_init().
Remove RTE_EXEC_ENV_BSDAPP in common file.
Changes in v3
Changed subject to be more explicit on file name inclusion.
Changes in v2
None
Changes in v1
Move common function in eal_lcore.c to librte_eal/common/
eal_common_lcore.c file.
Following function is moved to eal_common_lcore.c file
int rte_eal_cpu_init(void);
Use RTE_EXEC_ENV_BSDAPP to differentiate minor differences in
common function.
Makefile changes to reflect new file added.
Fix checkpatch warnings and errors.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/Makefile | 1 +
lib/librte_eal/bsdapp/eal/eal_lcore.c| 72 +
lib/librte_eal/common/eal_common_lcore.c | 107 +++
lib/librte_eal/common/eal_private.h | 14
lib/librte_eal/linuxapp/eal/Makefile | 2 +
lib/librte_eal/linuxapp/eal/eal_lcore.c | 66 ++-
6 files changed, 143 insertions(+), 119 deletions(-)
create mode 100644 lib/librte_eal/common/eal_common_lcore.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 67abc54..88d783d 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -64,6 +64,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_log.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_pci.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_lcore.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_lcore.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_timer.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_interrupts.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_alarm.c
diff --git a/lib/librte_eal/bsdapp/eal/eal_lcore.c
b/lib/librte_eal/bsdapp/eal/eal_lcore.c
index 162fb4f..b47eb1b 100644
--- a/lib/librte_eal/bsdapp/eal/eal_lcore.c
+++ b/lib/librte_eal/bsdapp/eal/eal_lcore.c
@@ -44,11 +44,14 @@
#include "eal_thread.h"
/* No topology information available on FreeBSD including NUMA info */
-#define cpu_core_id(X) 0
-#define cpu_socket_id(X) 0
+unsigned
+eal_cpu_core_id(__rte_unused unsigned lcore_id)
+{
+ return 0;
+}
static int
-get_ncpus(void)
+eal_get_ncpus(void)
{
int mib[2] = {CTL_HW, HW_NCPU};
int ncpu;
@@ -59,63 +62,18 @@ get_ncpus(void)
return ncpu;
}
-/*
- * fill the cpu_info structure with as much info as we can get.
- * code is similar to linux version, but sadly available info is less.
- */
-int
-rte_eal_cpu_init(void)
+unsigned
+eal_cpu_socket_id(__rte_unused unsigned cpu_id)
{
- /* pointer to global configuration */
- struct rte_config *config = rte_eal_get_configuration();
- unsigned lcore_id;
- unsigned count = 0;
-
- const unsigned ncpus = get_ncpus();
- /*
-* Parse the maximum set of logical cores, detect the subset of running
-* ones and enable them by default.
-*/
- for (lcore_id = 0; lcore_id < RTE_MAX_LCORE; lcore_id++) {
- /* init cpuset for per lcore config */
- CPU_ZERO(&lcore_config[lcore_id].cpuset);
-
- lcore_config[lcore_id].detected = (lcore_id < ncpus);
- if (lcore_config[lcore_id].detected == 0) {
- config->lcore_role[lcore_id] = ROLE_OFF;
- continue;
- }
-
- /* By default, lcore 1:1 map to cpu id */
- CPU_SET(lcore_id, &lcore_config[lcore_id].cpuset);
-
- /* By default, each detected core is enabled */
- config->lcore_role[lcore_id] = ROLE_RTE;
- lcore_config[lcore_id].core_id = cpu_core_id(lcore_id);
- lcore_config[lcore_id].socket_id = cpu_socket_id(lcore_id);
- if (lcore_config[lcore_id].socket_id >= RTE_MAX_NUMA_NODES)
-#ifdef RTE_EAL_ALLOW_INV_SOCKET_ID
- lcore_config[lcore_id].socket_id = 0;
-#else
- rte_panic("Socket ID (%u) is greater than "
- "RTE_MAX_NUMA_NODES (%d)\n",
- lcore_config[lcore_id].socket_id,
RTE_MAX_NUMA_NODES);
-#endif
- RTE_LOG(DEBUG, EAL, "Detected lcore %u\n",
- lcore_id);
- count++;
- }
- /* Set the count of enabled logical cores of the EAL configuration */
- config->lcore_count = count;
- RTE_LOG(DEBUG, EAL, "Support maximum %u logical core(s) by
configuration.\n",
- RTE_MAX_LCORE);
- RTE_LOG(DEBUG, EAL, "Detected %u lcore(s)\n", config->lcore_count);
-
return 0;
}
-unsigned
-eal_cpu_socket_id(__rte_unused unsigned cpu_id)
+/* Check if a cpu is present by the presence of the
+ * cpu information for it.
+ */
+int
+eal_cpu_detected(uns
[dpdk-dev] [PATCH v8 4/6] Move common functions in eal_timer.c
Changes in v8
Reorder eal_common_timer.c compilation.
Changes in v7
None
Changes in v6
Added new line between Copyright and header file inclusion
in eal_common_timer.c.
Changes in v5
Rebase to latest code.
Changes in v4
Removed extern declaration of eal_tsc_resolution_hz,
instead provided _set_ API.
Make set_tsc_freq_from_clock as wrapper function for BSD.
Changes in v3
Changed subject to be more explicit on file name inclusion.
Changes in v2
Use common function name set_tsc_freq_from_sysctl for BSD and Linux.
Update comments about its actuality in function declaration.
Changes in v1
Move common functions in eal_timer.c to librte_eal/common/
eal_common_timer.c file.
Following functions are moved to eal_common_timer.c file
void rte_delay_us(unsigned us);
uint64_t rte_get_tsc_hz(void);
static void set_tsc_freq_fallback(void);
void set_tsc_freq(void);
Makefile changes to reflect new file added.
Fix checkpatch warnings and errors.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/Makefile | 1 +
lib/librte_eal/bsdapp/eal/eal_timer.c| 52 +++-
lib/librte_eal/common/eal_common_timer.c | 102 +++
lib/librte_eal/common/eal_private.h | 24
lib/librte_eal/linuxapp/eal/Makefile | 1 +
lib/librte_eal/linuxapp/eal/eal_timer.c | 55 ++---
6 files changed, 140 insertions(+), 95 deletions(-)
create mode 100644 lib/librte_eal/common/eal_common_timer.c
diff --git a/lib/librte_eal/bsdapp/eal/Makefile
b/lib/librte_eal/bsdapp/eal/Makefile
index 88d783d..db52541 100644
--- a/lib/librte_eal/bsdapp/eal/Makefile
+++ b/lib/librte_eal/bsdapp/eal/Makefile
@@ -66,6 +66,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_debug.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_lcore.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_lcore.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_timer.c
+SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_common_timer.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_interrupts.c
SRCS-$(CONFIG_RTE_LIBRTE_EAL_BSDAPP) += eal_alarm.c
diff --git a/lib/librte_eal/bsdapp/eal/eal_timer.c
b/lib/librte_eal/bsdapp/eal/eal_timer.c
index 7147abe..ee7a5ac 100644
--- a/lib/librte_eal/bsdapp/eal/eal_timer.c
+++ b/lib/librte_eal/bsdapp/eal/eal_timer.c
@@ -55,29 +55,12 @@
enum timer_source eal_timer_source = EAL_TIMER_TSC;
-/* The frequency of the RDTSC timer resolution */
-static uint64_t eal_tsc_resolution_hz = 0;
-
-void
-rte_delay_us(unsigned us)
-{
- const uint64_t start = rte_get_timer_cycles();
- const uint64_t ticks = (uint64_t)us * rte_get_timer_hz() / 1E6;
- while ((rte_get_timer_cycles() - start) < ticks)
- rte_pause();
-}
-
-uint64_t
-rte_get_tsc_hz(void)
-{
- return eal_tsc_resolution_hz;
-}
-
static int
set_tsc_freq_from_sysctl(void)
{
size_t sz;
int tmp;
+ uint64_t tsc_hz;
sz = sizeof(tmp);
tmp = 0;
@@ -94,42 +77,23 @@ set_tsc_freq_from_sysctl(void)
else if (tmp != 1)
RTE_LOG(WARNING, EAL, "TSC is not invariant\n");
- sz = sizeof(eal_tsc_resolution_hz);
- if (sysctlbyname("machdep.tsc_freq", &eal_tsc_resolution_hz, &sz, NULL,
0)) {
+ sz = sizeof(tsc_hz);
+ if (sysctlbyname("machdep.tsc_freq", &tsc_hz, &sz, NULL, 0)) {
RTE_LOG(WARNING, EAL, "%s\n", strerror(errno));
return -1;
}
+ rte_set_tsc_hz(tsc_hz);
return 0;
}
-static void
-set_tsc_freq_fallback(void)
-{
- RTE_LOG(WARNING, EAL, "WARNING: clock_gettime cannot use "
- "CLOCK_MONOTONIC_RAW and HPET is not available"
- " - clock timings may be less accurate.\n");
- /* assume that the sleep(1) will sleep for 1 second */
- uint64_t start = rte_rdtsc();
- sleep(1);
- eal_tsc_resolution_hz = rte_rdtsc() - start;
-}
-
/*
- * This function measures the TSC frequency. It uses a variety of approaches.
- *
- * 1. Read the TSC frequency value provided by the kernel
- * 2. If above does not work, just sleep for 1 second and tune off that,
- *printing a warning about inaccuracy of timing
+ * Wrapper function to get TSC frequency from sysctl.
*/
-static void
-set_tsc_freq(void)
+int
+set_tsc_freq_from_clock(void)
{
- if (set_tsc_freq_from_sysctl() < 0)
- set_tsc_freq_fallback();
-
- RTE_LOG(INFO, EAL, "TSC frequency is ~%"PRIu64" KHz\n",
- eal_tsc_resolution_hz/1000);
+ return set_tsc_freq_from_sysctl();
}
int
diff --git a/lib/librte_eal/common/eal_common_timer.c
b/lib/librte_eal/common/eal_common_timer.c
new file mode 100644
index 000..5fddd6e
--- /dev/null
+++ b/lib/librte_eal/common/eal_common_timer.c
@@ -0,0 +1,102 @@
+/*-
+ * 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
+ * modificatio
[dpdk-dev] [PATCH v8 5/6] Move common functions in eal_memory.c
Changes in v8
None
Changes in v7
None
Changes in v6
Removed unnecessary comments in function declaration.
Changes in v5
Rebase to latest code.
Changes in v4
Make rte_eal_hugepage_init and rte_eal_hugepage_attach as
wrapper functions for BSD.
Changes in v3
Changed subject to be more explicit on file name inclusion.
Changes in v2
Use common function names rte_eal_hugepage_init and
rte_eal_hugepage_attach for BSD and Linux. Update comments about its
actuality in function declaration.
Changes in v1
Move common functions in eal_memory.c to librte_eal/common/
eal_common_memory.c file.
Following functions are moved to eal_common_memory.c file
static int rte_eal_memdevice_init(void); int rte_eal_memory_init(void);
Fix checkpatch warnings and errors.
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/eal_memory.c| 47 +++
lib/librte_eal/common/eal_common_memory.c | 38 +++--
lib/librte_eal/common/eal_private.h | 20 +++--
lib/librte_eal/linuxapp/eal/eal_memory.c | 36 ++-
4 files changed, 72 insertions(+), 69 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_memory.c
b/lib/librte_eal/bsdapp/eal/eal_memory.c
index 33ebd0f..77c27b3 100644
--- a/lib/librte_eal/bsdapp/eal/eal_memory.c
+++ b/lib/librte_eal/bsdapp/eal/eal_memory.c
@@ -59,7 +59,7 @@ rte_mem_virt2phy(const void *virtaddr)
return RTE_BAD_PHYS_ADDR;
}
-static int
+static inline int
rte_eal_contigmem_init(void)
{
struct rte_mem_config *mcfg;
@@ -131,7 +131,16 @@ rte_eal_contigmem_init(void)
return 0;
}
-static int
+/*
+ * Wrapper function to initialize contigmem.
+ */
+int
+rte_eal_hugepage_init(void)
+{
+ return rte_eal_contigmem_init();
+}
+
+static inline int
rte_eal_contigmem_attach(void)
{
const struct hugepage_info *hpi;
@@ -192,35 +201,11 @@ error:
return -1;
}
-
-static int
-rte_eal_memdevice_init(void)
-{
- struct rte_config *config;
-
- if (rte_eal_process_type() == RTE_PROC_SECONDARY)
- return 0;
-
- config = rte_eal_get_configuration();
- config->mem_config->nchannel = internal_config.force_nchannel;
- config->mem_config->nrank = internal_config.force_nrank;
-
- return 0;
-}
-
-/* init memory subsystem */
+/*
+ * Wrapper function to attach contigmem.
+ */
int
-rte_eal_memory_init(void)
+rte_eal_hugepage_attach(void)
{
- RTE_LOG(INFO, EAL, "Setting up physically contiguous memory...\n");
- const int retval = rte_eal_process_type() == RTE_PROC_PRIMARY ?
- rte_eal_contigmem_init() :
- rte_eal_contigmem_attach();
- if (retval < 0)
- return -1;
-
- if (internal_config.no_shconf == 0 && rte_eal_memdevice_init() < 0)
- return -1;
-
- return 0;
+ return rte_eal_contigmem_attach();
}
diff --git a/lib/librte_eal/common/eal_common_memory.c
b/lib/librte_eal/common/eal_common_memory.c
index 9a07b1e..10ff0bc 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -45,6 +45,7 @@
#include
#include "eal_private.h"
+#include "eal_internal_cfg.h"
/*
* Return a pointer to a read-only table of struct rte_physmem_desc
@@ -69,7 +70,7 @@ rte_eal_get_physmem_size(void)
/* get pointer to global configuration */
mcfg = rte_eal_get_configuration()->mem_config;
- for (i=0; imemseg[i].addr == NULL)
break;
@@ -89,7 +90,7 @@ rte_dump_physmem_layout(FILE *f)
/* get pointer to global configuration */
mcfg = rte_eal_get_configuration()->mem_config;
- for (i=0; imemseg[i].addr == NULL)
break;
@@ -118,3 +119,36 @@ unsigned rte_memory_get_nrank(void)
{
return rte_eal_get_configuration()->mem_config->nrank;
}
+
+static int
+rte_eal_memdevice_init(void)
+{
+ struct rte_config *config;
+
+ if (rte_eal_process_type() == RTE_PROC_SECONDARY)
+ return 0;
+
+ config = rte_eal_get_configuration();
+ config->mem_config->nchannel = internal_config.force_nchannel;
+ config->mem_config->nrank = internal_config.force_nrank;
+
+ return 0;
+}
+
+/* init memory subsystem */
+int
+rte_eal_memory_init(void)
+{
+ RTE_LOG(INFO, EAL, "Setting up physically contiguous memory...\n");
+ const int retval = rte_eal_process_type() == RTE_PROC_PRIMARY ?
+ rte_eal_hugepage_init() :
+ rte_eal_hugepage_attach();
+
+ if (retval < 0)
+ return -1;
+
+ if (internal_config.no_shconf == 0 && rte_eal_memdevice_init() < 0)
+ return -1;
+
+ return 0;
+}
diff --git a/lib/librte_eal/common/eal_private.h
b/lib/librte_eal/common/eal_private.h
index 8de4ebb..a51a68e 100644
--- a/lib/librte_eal/common/eal_private.h
+++ b/lib/librte_eal/common/eal_private.h
@@ -334,8 +334,6 @@ void set_tsc_freq(v
[dpdk-dev] [PATCH v8 6/6] Move common functions in eal_pci.c
Changes in v8
None
Changes in v7
Rebase to latest code.
Changes in v6
Split changes due to complexity. v6 includes moving
rte_eal_pci_probe_one_driver function and its associated
utility functions only.
Changes in v5
Rebase to latest code.
Removed RTE_EXEC_ENV_BSDAPP from earlier changes.
Changes in v4
Move common functions in eal_pci.c to librte_eal/common/
eal_common_pci.c file.
Following functions are moved to eal_common_pci.c file.
void *pci_map_resource(void *requested_addr, const int vfio_fd,
const char *devname, off_t offset, size_t size);
int pci_addr_comparison(struct rte_pci_addr *addr,
struct rte_pci_addr *addr2);
int rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr,
struct rte_pci_device *dev);
Use RTE_EXEC_ENV_BSDAPP to differentiate minor differences in
common function.
Fix checkpatch warnings and errors.
Changes in v3
N/A
Changes in v2
N/A
Changes in v1
N/A
Signed-off-by: Ravi Kerur
---
lib/librte_eal/bsdapp/eal/eal_pci.c| 72 +---
lib/librte_eal/common/eal_common_pci.c | 72
lib/librte_eal/common/eal_private.h| 39 +-
lib/librte_eal/linuxapp/eal/eal_pci.c | 75 +-
4 files changed, 113 insertions(+), 145 deletions(-)
diff --git a/lib/librte_eal/bsdapp/eal/eal_pci.c
b/lib/librte_eal/bsdapp/eal/eal_pci.c
index 30f0232..f21b5b6 100644
--- a/lib/librte_eal/bsdapp/eal/eal_pci.c
+++ b/lib/librte_eal/bsdapp/eal/eal_pci.c
@@ -111,7 +111,7 @@ static struct rte_tailq_elem rte_uio_tailq = {
EAL_REGISTER_TAILQ(rte_uio_tailq)
/* unbind kernel driver for this device */
-static int
+int
pci_unbind_kernel_driver(struct rte_pci_device *dev __rte_unused)
{
RTE_LOG(ERR, EAL, "RTE_PCI_DRV_FORCE_UNBIND flag is not implemented "
@@ -274,6 +274,13 @@ pci_uio_map_resource(struct rte_pci_device *dev)
return (0);
}
+/* map the PCI resource of a PCI device in virtual memory */
+int
+pci_map_device(struct rte_pci_device *dev)
+{
+ return pci_uio_map_resource(dev);
+}
+
/* Scan one pci sysfs entry, and fill the devices list from it. */
static int
pci_scan_one(int dev_pci_fd, struct pci_conf *conf)
@@ -426,68 +433,11 @@ error:
}
/*
- * If vendor/device ID match, call the devinit() function of the
- * driver.
+ * This function is a no-op in BSD.
*/
-int
-rte_eal_pci_probe_one_driver(struct rte_pci_driver *dr, struct rte_pci_device
*dev)
+void
+pci_config_space_set(struct rte_pci_device *dev __rte_unused)
{
- struct rte_pci_id *id_table;
- int ret;
-
- for (id_table = dr->id_table ; id_table->vendor_id != 0; id_table++) {
-
- /* check if device's identifiers match the driver's ones */
- if (id_table->vendor_id != dev->id.vendor_id &&
- id_table->vendor_id != PCI_ANY_ID)
- continue;
- if (id_table->device_id != dev->id.device_id &&
- id_table->device_id != PCI_ANY_ID)
- continue;
- if (id_table->subsystem_vendor_id !=
dev->id.subsystem_vendor_id &&
- id_table->subsystem_vendor_id != PCI_ANY_ID)
- continue;
- if (id_table->subsystem_device_id !=
dev->id.subsystem_device_id &&
- id_table->subsystem_device_id != PCI_ANY_ID)
- continue;
-
- struct rte_pci_addr *loc = &dev->addr;
-
- RTE_LOG(DEBUG, EAL, "PCI device "PCI_PRI_FMT" on NUMA socket
%i\n",
- loc->domain, loc->bus, loc->devid,
loc->function,
- dev->numa_node);
-
- RTE_LOG(DEBUG, EAL, " probe driver: %x:%x %s\n",
dev->id.vendor_id,
- dev->id.device_id, dr->name);
-
- /* no initialization when blacklisted, return without error */
- if (dev->devargs != NULL &&
- dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI) {
-
- RTE_LOG(DEBUG, EAL, " Device is blacklisted, not
initializing\n");
- return 0;
- }
-
- if (dr->drv_flags & RTE_PCI_DRV_NEED_MAPPING) {
- /* map resources for devices that use igb_uio */
- ret = pci_uio_map_resource(dev);
- if (ret != 0)
- return ret;
- } else if (dr->drv_flags & RTE_PCI_DRV_FORCE_UNBIND &&
- rte_eal_process_type() == RTE_PROC_PRIMARY) {
- /* unbind current driver */
- if (pci_unbind_kernel_driver(dev) < 0)
- return -1;
- }
-
- /* reference driver structure */
- dev->driver = dr;
-
- /* call the driver devin
[dpdk-dev] [PATCH v7 1/6] Move common functions in eal_thread.c
On Tue, Apr 28, 2015 at 12:35 PM, Neil Horman wrote: > On Mon, Apr 27, 2015 at 03:39:41PM -0700, Ravi Kerur wrote: > > On Mon, Apr 27, 2015 at 6:44 AM, Neil Horman > wrote: > > > > > On Sat, Apr 25, 2015 at 05:09:01PM -0700, Ravi Kerur wrote: > > > > On Sat, Apr 25, 2015 at 6:02 AM, Neil Horman > > > wrote: > > > > > > > > > On Sat, Apr 25, 2015 at 08:32:42AM -0400, Neil Horman wrote: > > > > > > On Fri, Apr 24, 2015 at 06:45:06PM -0700, Ravi Kerur wrote: > > > > > > > On Fri, Apr 24, 2015 at 2:24 PM, Ravi Kerur > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 24, 2015 at 12:51 PM, Neil Horman < > > > nhorman at tuxdriver.com > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > >> On Fri, Apr 24, 2015 at 12:21:23PM -0700, Ravi Kerur wrote: > > > > > > > >> > On Fri, Apr 24, 2015 at 11:53 AM, Neil Horman < > > > > > nhorman at tuxdriver.com> > > > > > > > >> wrote: > > > > > > > >> > > > > > > > > >> > > On Fri, Apr 24, 2015 at 09:45:24AM -0700, Ravi Kerur > wrote: > > > > > > > >> > > > On Fri, Apr 24, 2015 at 8:22 AM, Neil Horman < > > > > > nhorman at tuxdriver.com > > > > > > > >> > > > > > > > > >> > > wrote: > > > > > > > >> > > > > > > > > > > >> > > > > On Fri, Apr 24, 2015 at 08:14:04AM -0700, Ravi Kerur > > > wrote: > > > > > > > >> > > > > > On Fri, Apr 24, 2015 at 6:51 AM, Neil Horman < > > > > > > > >> nhorman at tuxdriver.com> > > > > > > > >> > > > > wrote: > > > > > > > >> > > > > > > > > > > > > >> > > > > > > On Thu, Apr 23, 2015 at 02:35:31PM -0700, Ravi > Kerur > > > > > wrote: > > > > > > > >> > > > > > > > Changes in v7 > > > > > > > >> > > > > > > > Remove _setname_ pthread calls. > > > > > > > >> > > > > > > > Use rte_gettid() API in RTE_LOG to print > > > thread_id. > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v6 > > > > > > > >> > > > > > > > Remove RTE_EXEC_ENV_BSDAPP from > > > eal_common_thread.c > > > > > file. > > > > > > > >> > > > > > > > Add pthread_setname_np/pthread_set_name_np for > > > > > Linux/FreeBSD > > > > > > > >> > > > > > > > respectively. Plan to use _getname_ in RTE_LOG > > > when > > > > > > > >> available. > > > > > > > >> > > > > > > > Use existing rte_get_systid() in RTE_LOG to > print > > > > > thread_id. > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v5 > > > > > > > >> > > > > > > > Rebase to latest code. > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v4 > > > > > > > >> > > > > > > > None > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v3 > > > > > > > >> > > > > > > > Changed subject to be more explicit on file > name > > > > > inclusion. > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v2 > > > > > > > >> > > > > > > > None > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Changes in v1 > > > > > > > >> > > > > > > > eal_thread.c has minor differences between > Linux > > > and > > > > > BSD, > > > > > > > >> move > > > > > > > >> > > > > > > > entire file into common directory. > > > > > > > >> > > > > > > > Use RTE_EXEC_ENV_BSDAPP to differentiate on > minor > > > > > > > >> differences. > > > > > > > >> > > > > > > > Rename eal_thread.c to eal_common_thread.c > > > > > > > >> > > > > > > > Makefile changes to reflect file move and name > > > change. > > > > > > > >> > > > > > > > Fix checkpatch warnings. > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > Signed-off-by: Ravi Kerur > > > > > > > >> > > > > > > > --- > > > > > > > >> > > > > > > > lib/librte_eal/bsdapp/eal/Makefile| > 2 > > > +- > > > > > > > >> > > > > > > > lib/librte_eal/bsdapp/eal/eal_thread.c| > 152 > > > > > > > >> > > > > > > -- > > > > > > > >> > > > > > > > lib/librte_eal/common/eal_common_thread.c | > 147 > > > > > > > >> > > > > > > - > > > > > > > >> > > > > > > > lib/librte_eal/linuxapp/eal/eal_thread.c | > 152 > > > > > > > >> > > > > > > +- > > > > > > > >> > > > > > > > 4 files changed, 148 insertions(+), 305 > > > deletions(-) > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > diff --git > a/lib/librte_eal/bsdapp/eal/Makefile > > > > > > > >> > > > > > > b/lib/librte_eal/bsdapp/eal/Makefile > > > > > > > >> > > > > > > > index 2357cfa..55971b9 100644 > > > > > > > >> > > > > > > > --- a/lib/librte_eal/bsdapp/eal/Makefile > > > > > > > >> > > > > > > > +++ b/lib/librte_eal/bsdapp/eal/Makefile > > > > > > > >> > > > > > > > @@ -87,7 +87,7 @@ CFLAGS_eal_common_log.o := > > > > > -D_GNU_SOURCE > > > > > > > >> > > > > > > > # workaround for a gcc bug with noreturn > > > attribute > > > > > > > >> > > > > > > > # > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 > > > > > > > >> > > > > > > > ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) > > > > > > > >> > > > > > > > -CFLAGS_eal_thread.o += -Wno-return-type > > > > > > > >> > > > > > > > +CFLAGS_eal_common
[dpdk-dev] gmake test on freeBSD
DPDK team, Is there a automated tests to run on freeBSD similar to Linux (make test). I ran "gmake test T=x86_64-native-bsdapp-clang CC=clang" I get following output /usr/home/rkerur/dpdk-validate-abi-1/dpdk/build/app/test -c f -n 4 Test name Test result Test Total Start group_1: Fail [Can't run] [00m 00s] Timer autotest:Fail [Can't run] [00m 00s] Debug autotest:Fail [Can't run] [00m 00s] Errno autotest:Fail [Can't run] [00m 00s] Meter autotest:Fail [Can't run] [00m 00s] Common autotest: Fail [Can't run] [00m 00s] Dump log history: Fail [Can't run] [00m 00s] ... Start memcpy_perf: Fail [No prompt] [00m 00s] Memcpy performance autotest: Fail [No prompt] [00m 00s] [00m 01s] Start hash_perf: Fail [No prompt] [00m 00s] Hash performance autotest: Fail [No prompt] [00m 00s] [00m 01s] Start power: Fail [No prompt] [00m 00s] Power autotest:Fail [No prompt] [00m 00s] [00m 01s] ... I have contigmem and nic_uio installed. I know some applications are linuxapp specific but wanted to know if there is a similar automated test tool like Linux? Thanks, Ravi
