[dpdk-dev] rte_ixgbevf_pmd not reporting dropped packets
Hi all, I'm using DPDK inside the OS of a VM that is SR-IOV-accelerated. I noticed however that the "rte_ixgbevf_pmd" PMD does not report drops... I am sending packets at TX side at 14Mpps; at the RX side I'm using "testpmd" and it's reporting 'just' 12Mpps, but zero drops (also through xstats). Is this a known bug? I found a message at http://dpdk.org/ml/archives/dev/2016-March/035374.html reporting a similar issue back in March this year... Thanks, Francesco Montorsi
[dpdk-dev] how to search this mailing list? is gmane link archive broken?
Hi all, if this was already raised, sorry for that. I noticed that the gmane archive for this mailing list is not working anymore: http://news.gmane.org/gmane.comp.networking.dpdk.devel reports "Page not found". Also I noticed that the gmane link on the dpdk.org website has been removed. That was my only way to search through the archives of this mailing list... is there any other way to search them? Thanks, Francesco Montorsi
[dpdk-dev] Proposal: enable redirection of DPDK logs from the user app
Hi Olivier, > On 10/04/2016 02:28 PM, Montorsi, Francesco wrote: > > Yes, but to be honest, that seems a troublesome solution for something > > as easy as logging a string; e.g. by using fopencookie() approach, you > > don't have the concept of "log message", you just provide a function > > that must write a block of bytes somewhere. > > Typically instead, you need to know where a log message starts and > > ends, to e.g., add prefixes/postfixes to it. > > I'm not sure that true if you call setbuf(log_stream, NULL). > > In that case, it looks easy to prefix / postfix messages with a fopencookie > callback like: > > /* example on stdout */ > ssize_t > simple_write(void *c, const char *buf, size_t size) { > ssize_t ret1, ret2, ret3; > > ret1 = fwrite("<", 1, 1, stdout); > if (ret1 == 0) > return 0; > ret2 = fwrite(buf, size, 1, stdout); > if (ret2 == 0) > return 0; > ret3 = fwrite(">", 1, 1, stdout); > if (ret3 == 0) > return 0; > return ret1 + ret2 + ret3; > } > I didn't know about setbuf()... but are we sure that in this way the simple_write() function will always receive a full string? I mean: in the manpage for setbuf() it says: "... When the first I/O operation occurs on a file, malloc(3) is called, and a buffer is obtained. If the argument buf is NULL, only the mode is affected; a new buffer will be allocated on the next read or write operation." But: is it true that 1 write operation corresponds to 1 vfprintf() call? Maybe if you have a "long" a single vfprintf() call may translate to several simple_write() calls... I don't know honestly. > > Indeed, most of the C/C++ (open source) libraries have some simple > > hook that allows the user to have more control on logging... I think > > DPDK should be no exception... :) > > I understand that the current API is a bit more complex, but I don't feel > there > is any blocking issue to do what you want. What do you think? See above. Moreover, IMHO it would be much more user-friendly to have a simple function callback to implement vs having to dig into fopencookie()+setbuf()+etc etc . > Also, I know you've said your patch needs some rework, but as you've also > said you are using it, maybe it would be useful for you to know: > - it makes use of a global variable 'log_buffer', shared by all the pthreads, > which can lead to crashes That's a good point. I will turn it into a __thread variable. Thanks for pointing out this. > - it strips the log messages to 4095 chars Correct, but in my experience DPDK never creates such a long line of log message... Francesco
[dpdk-dev] Proposal: enable redirection of DPDK logs from the user app
Hi Olivier, > It seems the mailing list stripped your patch sent as attachment. > Can you please resend it again in the body of the mail? You're right sorry. It's attached at the end of this mail. > I think we can already redirect logs to a file by using fopencookie() + > rte_openlog_stream(). Did you already check these functions? Yes, but to be honest, that seems a troublesome solution for something as easy as logging a string; e.g. by using fopencookie() approach, you don't have the concept of "log message", you just provide a function that must write a block of bytes somewhere. Typically instead, you need to know where a log message starts and ends, to e.g., add prefixes/postfixes to it. Indeed, most of the C/C++ (open source) libraries have some simple hook that allows the user to have more control on logging... I think DPDK should be no exception... :) Thanks, Francesco >From 52d4fdccee4de3787e85589ff8f666028ad9ea7b Mon Sep 17 00:00:00 2001 From: Francesco MontorsiDate: Tue, 4 Oct 2016 12:08:34 +0200 Subject: [PATCH] Enable custom log sink implementations --- lib/librte_eal/common/eal_common_log.c | 23 --- lib/librte_eal/common/include/rte_log.h | 8 ++-- lib/librte_eal/linuxapp/eal/eal_debug.c | 16 ++-- lib/librte_eal/linuxapp/eal/rte_eal_version.map | 2 +- 4 files changed, 41 insertions(+), 8 deletions(-) diff --git a/lib/librte_eal/common/eal_common_log.c b/lib/librte_eal/common/eal_common_log.c index 967991a..5e86309 100644 --- a/lib/librte_eal/common/eal_common_log.c +++ b/lib/librte_eal/common/eal_common_log.c @@ -41,15 +41,25 @@ #include "eal_private.h" + +/* forward declaration */ +int +rte_vlog_to_FILE(uint32_t level, uint32_t logtype, const char *formattedstr); + /* global log structure */ struct rte_logs rte_logs = { .type = ~0, .level = RTE_LOG_DEBUG, .file = NULL, + .log_callback = rte_vlog_to_FILE }; static FILE *default_log_stream; +#define LOG_BUFFER_SIZE4095 +static char log_buffer[LOG_BUFFER_SIZE+1]; + + /** * This global structure stores some informations about the message * that is currently beeing processed by one lcore @@ -123,7 +133,7 @@ int rte_log_cur_msg_logtype(void) * defined by the previous call to rte_openlog_stream(). */ int -rte_vlog(uint32_t level, uint32_t logtype, const char *format, va_list ap) +rte_vlog_to_FILE(uint32_t level, uint32_t logtype, const char *formattedstr) { int ret; FILE *f = rte_logs.file; @@ -135,11 +145,16 @@ rte_vlog(uint32_t level, uint32_t logtype, const char *format, va_list ap) RTE_PER_LCORE(log_cur_msg).loglevel = level; RTE_PER_LCORE(log_cur_msg).logtype = logtype; - ret = vfprintf(f, format, ap); + ret = fprintf(f, "%s", formattedstr); fflush(f); return ret; } +void rte_set_custom_vlog(rte_vlog_func_t callback) +{ + rte_logs.log_callback = callback; +} + /* * Generates a log message The message will be sent in the stream * defined by the previous call to rte_openlog_stream(). @@ -152,8 +167,10 @@ rte_log(uint32_t level, uint32_t logtype, const char *format, ...) int ret; va_start(ap, format); - ret = rte_vlog(level, logtype, format, ap); + vsnprintf(log_buffer, LOG_BUFFER_SIZE, format, ap); va_end(ap); + + ret = rte_logs.log_callback(level, logtype, log_buffer); return ret; } diff --git a/lib/librte_eal/common/include/rte_log.h b/lib/librte_eal/common/include/rte_log.h index 919563c..3dcb135 100644 --- a/lib/librte_eal/common/include/rte_log.h +++ b/lib/librte_eal/common/include/rte_log.h @@ -50,11 +50,15 @@ extern "C" { #include #include +/** The backend used for logging. Can be user-defined. */ +typedef int (*rte_vlog_func_t)(uint32_t level, uint32_t logtype, const char *formattedstr); + /** The rte_log structure. */ struct rte_logs { uint32_t type; /**< Bitfield with enabled logs. */ uint32_t level; /**< Log level. */ FILE *file; /**< Pointer to current FILE* for logs. */ + rte_vlog_func_t log_callback; }; /** Global log informations */ @@ -236,8 +240,8 @@ int rte_log(uint32_t level, uint32_t logtype, const char *format, ...) * - 0: Success. * - Negative on error. */ -int rte_vlog(uint32_t level, uint32_t logtype, const char *format, va_list ap) - __attribute__((format(printf,3,0))); +void rte_set_custom_vlog(rte_vlog_func_t callback); + /** * Generates a log message. diff --git a/lib/librte_eal/linuxapp/eal/eal_debug.c b/lib/librte_eal/linuxapp/eal/eal_debug.c index 5fbc17c..f411d96 100644 --- a/lib/librte_eal/linuxapp/eal/eal_debug.c +++ b/lib/librte_eal/linuxapp/eal/eal_debug.c @@ -78,9 +78,16 @@ void __rte_panic(const char *funcname, const char *format, ...) va_list ap; rte_log(RTE_LOG_CRIT, RTE_LOGTYPE_EAL, "PANIC in %s():\n", funcname);
[dpdk-dev] Proposal: enable redirection of DPDK logs from the user app
Hi all, I've not been following closely latest DPDK activity but my company is using DPDK and we recently upgraded to 16.07. We apply several patches to DPDK sources, to make it more similar to a "standard library" (currently it is quite intrusive: calls abort() at will, writes its own log, etc etc)... I think that it may be useful to give back to the community some of these (small) "enhancements". One of them is about logging: as the application where we embed DPDK already has its log file, we want DPDK to log in our log facility framework. My "fix" is simple: I just put a callback function in RTE logging system that, by default, points to the existing rte_vlog() function. If needed the library user can provide its own callback function to do what he likes. The attached patch is what we use right now. I totally understand it needs some rework to put it in a better shape... but first of all: are you interested in such patch? Thanks, Francesco Montorsi
[dpdk-dev] where to find ethernet CRC when stripping is off
Hi all, I need to get access to the Ethernet CRC of received packets. To do this, I'm configuring: port_conf.rxmode.hw_strip_crc = 0; Now my question is: how am I supposed to access the Ethernet CRC from a DPDK mbuf? Is the CRC just the 4 final bytes of the packets? Is this correct: uint32_t crc = rte_pktmbuf_mtod_offset (mymbuf, uint32_t*, mymbuf->pkt_len) ; ? Thanks, Francesco Montorsi
[dpdk-dev] rte_eth_tx_queue_setup() failing (error -22) when setting up tx queues on a VMXNET3 port...
Hi Stephen, > -Original Message- > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > If you read the source, you will see that it there are log messages enabled if > you configure with LIBRTE_ETHDEV_DEBUG enabled and rebuild DPDK. And > there are log messages for VMXNETE3 controlled by > LIBRTE_VMXNET3_DEBUG_INIT Thanks for this hint. I didn't know actually where to read... anyway enabling these additional debug messages I found the cause of the problem: the minimal TX queue ring size for VMXNET3 is 512; I was passing 64. Fixed this problem, I'm now on the next one I discovered that apparently the driver for VMXNET3 supports only a limited set of functions: (gdb) p *dev->dev_ops $3 = {dev_configure = 0x75cda5 , dev_start = 0x75d653 , dev_stop = 0x75d799 , dev_set_link_up = 0, dev_set_link_down = 0, dev_close = 0x75d8ab , promiscuous_enable = 0x75dd12 , promiscuous_disable = 0x75ddf6 , allmulticast_enable = 0x75df0c , allmulticast_disable = 0x75df40 , link_update = 0x75dbd9 , stats_get = 0x75d8fe , stats_reset = 0, xstats_get = 0, xstats_reset = 0, queue_stats_mapping_set = 0, dev_infos_get = 0x75db7f , mtu_set = 0, vlan_filter_set = 0x75df74 , vlan_tpid_set = 0, vlan_strip_queue_set = 0, vlan_offload_set = 0x75e455 , vlan_pvid_set = 0, rx_queue_start = 0, rx_queue_stop = 0, tx_queue_start = 0, tx_queue_stop = 0, rx_queue_setup = 0x75bfb8 , rx_queue_release = 0x74b069 , rx_queue_count = 0, rx_descriptor_done = 0, rx_queue_intr_enable = 0, rx_queue_intr_disable = 0, tx_queue_setup = 0x75bbc6 , tx_queue_release = 0x74b03c , dev_led_on = 0, dev_led_off = 0, flow_ctrl_get = 0, flow_ctrl_set = 0, priority_flow_ctrl_set = 0, mac_addr_remove = 0, mac_addr_add = 0, mac_addr_set = 0, uc_hash_table_set = 0, uc_all_hash_table_set = 0, mirror_rule_set = 0, mirror_rule_reset = 0, set_vf_rx_mode = 0, set_vf_rx = 0, set_vf_tx = 0, set_vf_vlan_filter = 0, udp_tunnel_add = 0, udp_tunnel_del = 0, set_queue_rate_limit = 0, set_vf_rate_limit = 0, fdir_add_signature_filter = 0, fdir_update_signature_filter = 0, fdir_remove_signature_filter = 0, fdir_infos_get = 0, fdir_add_perfect_filter = 0, fdir_update_perfect_filter = 0, fdir_remove_perfect_filter = 0, fdir_set_masks = 0, reta_update = 0, reta_query = 0, get_reg_length = 0, get_reg = 0, get_eeprom_length = 0, get_eeprom = 0, set_eeprom = 0, rss_hash_update = 0, rss_hash_conf_get = 0, filter_ctrl = 0, set_mc_addr_list = 0, timesync_enable = 0, timesync_disable = 0, timesync_read_rx_timestamp = 0, timesync_read_tx_timestamp = 0} Since I was using the rte_eth_rx_queue_count() function in one place, and VMXNET3 does not support it, I'm getting a SEGFAULT. So next question is: is user's task to check for validity of pointers inside dev_ops before calling driver functions? Because rte_eth_rx_queue_count() and companion funcitons have no safety checks apparently (!!!) Thanks! Francesco
[dpdk-dev] rte_eth_tx_queue_setup() failing (error -22) when setting up tx queues on a VMXNET3 port...
Hi all, I have a server running VMWare ESXi 5.5.0 and VMWare vCenter 5.5.0. On such server I created a VM with two VMXNET3 NIC cards (one for management, the other one should be used with DPDK to enable fast-RX of packets coming from other VMs / bare-metal NICs). Inside the VM I have successfully created 2MB hugepages, loaded igb_uio driver and binded the 2nd VMXNET3 NIC to igb_uio driver: -- $ ./dpdk_nic_bind.py --status Network devices using DPDK-compatible driver :0b:00.0 'VMXNET3 Ethernet Controller' drv=igb_uio unused=vmxnet3 Network devices using kernel driver === :03:00.0 'VMXNET3 Ethernet Controller' if=eth0 drv=vmxnet3 unused=igb_uio *Active* Other network devices = -- However when I start my DPDK-application I get the following error during TX queue initialization: ERR rte_eth_tx_queue_setup: err=-22, port=0: Unknown error -22 This is the code that I'm using: ... rte_eth_dev_info_get(m_portid, m_dev_info); // proceed with configuration struct rte_eth_conf port_conf; memset(_conf, 0, sizeof(port_conf)); port_conf.rxmode.mq_mode = ETH_MQ_RX_RSS; /** The multi-queue packet distribution mode to be used, e.g. RSS.; this is important to use multiple RX queues per port ID */ port_conf.rxmode.max_rx_pkt_len = ETHER_MAX_LEN; port_conf.rxmode.hw_strip_crc = 1; /**< enable CRC stripping by hardware */ port_conf.rxmode.jumbo_frame= 1; /**< Jumbo Frame Support enabled */ //port_conf.rxmode.enable_lro = 1; /**< Enable LRO */ // NOT SUPPORTED ON TESTED HW port_conf.rx_adv_conf.rss_conf.rss_hf = ETH_RSS_IP; port_conf.txmode.mq_mode = ETH_MQ_TX_NONE; m_num_queues = MIN(64, m_dev_info->max_rx_queues); m_num_queues = MIN(128, m_num_queues); ret = rte_eth_dev_configure(m_portid, m_num_queues, 1 /* number of tx queues */, _conf); if (ret < 0) { HMLogError("HwEmulDPDKPort::init() rte_eth_dev_configure: err=%d, port=%u: %s", ret, m_portid, rte_strerror(ret)); return false; } // init one TX queue: even if we never ever TX packets, at least 1 queue is needed! --->ret = rte_eth_tx_queue_setup(m_portid, 0 /* queue ID */, 64 /* num descriptors */, rte_eth_dev_socket_id(m_portid), NULL); if (ret < 0) { // retry with just 1 descriptor --->ret = rte_eth_tx_queue_setup(m_portid, 0 /* queue ID */, 1 /* num descriptors */, rte_eth_dev_socket_id(m_portid), NULL); if (ret < 0) { HMLogError("HwEmulDPDKPort::init() rte_eth_tx_queue_setup: err=%d, port=%u: %s", ret, m_portid, rte_strerror(ret)); return false; } } Basically since I want to only receive packets (no TX) I'm not really interested in TX queues / num of TX descriptors... However I have troubles decrypting this -22 error code... any hint? Thanks a lot, Francesco Montorsi
[dpdk-dev] Permanently binding NIC ports with DPDK drivers
Hi John, > -Original Message- > From: Mcnamara, John [mailto:john.mcnamara at intel.com] > > The Ubuntu dpdk package for 15.10 contains system scripts with functions for > reserving hugepages and binding interfaces on bootup: > > > /etc/dpdk/dpdk.conf > /etc/dpdk/interfaces > /etc/init.d/dpdk > /lib/dpdk/dpdk-init > /lib/systemd/system/dpdk.service > /sbin/dpdk_nic_bind > /usr/bin/testpmd > /usr/share/doc/dpdk/README.Debian > /usr/share/doc/dpdk/changelog.Debian.gz > /usr/share/doc/dpdk/copyright > /usr/share/dpdk/tools/cpu_layout.py > /usr/share/dpdk/tools/dpdk_nic_bind.py > /usr/share/dpdk/tools/setup.sh > /usr/share/python/runtime.d/dpdk.rtupdate > > http://packages.ubuntu.com/wily/amd64/dpdk/filelist > > If you have the latest version of Ubuntu you can check that out or else > download and extract the files from the .deb to see how they do it. > This certainly looks very useful. I inspected the package and the files you mentioned and indeed it looks like a good way to go, specially if Ubuntu distribution is moving in that direction (hopefully other distros will follow too). Thanks a lot! Francesco
[dpdk-dev] Permanently binding NIC ports with DPDK drivers
Hi Panu, > -Original Message- > From: Panu Matilainen [mailto:pmatilai at redhat.com] > I've been looking into this recently, here's what I have so far: > http://laiskiainen.org/git/?p=driverctl.git > Thanks I tried the script (I just had to change /bin/sh into /bin/bash on first line) and it works fine on my Ubuntu 14.04. Unfortunately I'm forced to run my sw on SLES 11.3 (which btw uses kernel 3.0.76 which I don't know if is compatible with VFIO) and there the output of "list-devices" is plain empty. I will try to look at what's happening... Thanks, Francesco
[dpdk-dev] Permanently binding NIC ports with DPDK drivers
Hi Bruce, > -Original Message- > From: Bruce Richardson [mailto:bruce.richardson at intel.com] > I'm not aware of any way to make the bindings permanent across reboots. > What you have suggested will work, but there are probably better ways to > do the same thing. I agree... let's see if somebody else has suggestions :) In any case my idea is to make my software as much independent as possible from troubles with future HW and future DPDK versions. A way to do that would be to leave all the bind steps and intelligence inside the dpdk_nic_bind.py script and just use that (since it will be probably always up to date and correct). My only concern is that (reading the python code) dpdk_nic_bind.py script does not return with an error code != 0 if something bad happens during binding... maybe it may be worth doing such a small change... Just my 2 cents, Francesco
[dpdk-dev] Permanently binding NIC ports with DPDK drivers
Hi, Is there a way to permanently (i.e., have the configuration automatically applied after reboot) bind a NIC port to DPDK? In case there's none, I'm thinking to save in my software a list of the NIC ports chosen by the user for use with DPDK and then, upon software startup to just do for (int i=0; i < ...; i++) system("dpdk_nic_bind.py --bind=igb_uio " + PCI_device_chosen[i]); Do you see any problem with that? Thanks! Francesco Montorsi
[dpdk-dev] how to use multiple RX queues on the same port
Hi Pablo, > -Original Message- > From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch at intel.com] > > Hi all, > > To avoid rx_nombuf packet drops, I'm trying to configure a DPDK port > > to use more than 1 RX queue... so I'm trying (on a 10Gbps card) to use 4 RX > queues. > > The call to rte_eth_dev_configure() and the 4 calls to > > rte_eth_rx_queue_setup() succeed but then via the > > rte_eth_rx_queue_count() API I see that only the first RX queue is > > used. The remaining 3 seems unused... am I missing something? > > How are you configuring the port? Are you using RSS? I guess that's what you > are looking for, so make sure that you are using the right > mq_mode(ETH_MQ_RX_RSS). No, I was not using RSS and this was indeed the problem. I enabled it as is done in e.g., l3fwd example, i.e., using the ETH_RSS_IP for the hash functions to apply. I now see that all 4 RX queues are correctly used. Thanks!! Francesco
[dpdk-dev] how to get driver name for a given port ID
Hi, Just as reference for other DPDK users: the solution to the problem is simple: rte_eth_dev_info_get (uint8_t port_id, struct rte_eth_dev_info *dev_info) returns a dev_info structure that contains "driver_name"... HTH, Francesco > -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Montorsi, > Francesco > Sent: luned? 26 ottobre 2015 15:18 > To: dev at dpdk.org > Subject: [dpdk-dev] how to get driver name for a given port ID > > Hi all, > > Is there an API to retrieve the driver name for a certain port ID before > calling > rte_eth_dev_configure()? > > My use case is: I'm trying to call rte_eth_dev_configure() with nb_rx_q=4 > and found that this works for ixgbe driver but it doesn't for "rte_em_pmd" > (1Gbps device): > > ERROR HwEmulDPDKPort::init() rte_eth_dev_configure: err=-22, port=0: > Unknown error -22 > EAL: PCI device :03:00.0 on NUMA socket 0 > EAL: remove driver: 8086:105e rte_em_pmd > EAL: PCI memory unmapped at 0x7feb4000 > EAL: PCI memory unmapped at 0x7feb4002 > > So, for those devices I want to use nb_rx_q=1... > > Thanks, > > Francesco Montorsi
[dpdk-dev] how to use multiple RX queues on the same port
Hi all, To avoid rx_nombuf packet drops, I'm trying to configure a DPDK port to use more than 1 RX queue... so I'm trying (on a 10Gbps card) to use 4 RX queues. The call to rte_eth_dev_configure() and the 4 calls to rte_eth_rx_queue_setup() succeed but then via the rte_eth_rx_queue_count() API I see that only the first RX queue is used. The remaining 3 seems unused... am I missing something? Thanks! Francesco Montorsi
[dpdk-dev] how to get driver name for a given port ID
Hi all, Is there an API to retrieve the driver name for a certain port ID before calling rte_eth_dev_configure()? My use case is: I'm trying to call rte_eth_dev_configure() with nb_rx_q=4 and found that this works for ixgbe driver but it doesn't for "rte_em_pmd" (1Gbps device): ERROR HwEmulDPDKPort::init() rte_eth_dev_configure: err=-22, port=0: Unknown error -22 EAL: PCI device :03:00.0 on NUMA socket 0 EAL: remove driver: 8086:105e rte_em_pmd EAL: PCI memory unmapped at 0x7feb4000 EAL: PCI memory unmapped at 0x7feb4002 So, for those devices I want to use nb_rx_q=1... Thanks, Francesco Montorsi
[dpdk-dev] Accurate timestamps in received packets
Hi John, Thanks for your reply. > -Original Message- > From: Mcnamara, John [mailto:john.mcnamara at intel.com] > AFAIK, timestamping of every packet isn't supported by ixgbe/i40e nics and I > don't know about non-Intel nics. It was supported for some(?) igb nics and > hence the patch you linked to. Also, there isn't any DPDK API to > enable/disable it even if it is supported by the nic. What a pity, that's a bad news for me. Another question in case you know: AFAIUI ixgbe/i40e devices receive packets in burst/sequences. What's the timeout for flushing the receive queue? In other words, if I send a single packet to the PHY of the NIC, after how much time will the Intel network controller will stop waiting for further packets (to put in the same "burst") and send that single packet to the CPU? Thanks, Francesco
[dpdk-dev] Accurate timestamps in received packets
Hi Wenzhuo, > -Original Message- > From: Lu, Wenzhuo [mailto:wenzhuo.lu at intel.com] > Hi Francesco, > Why not searching ieee1588 in the dpdk git repository? Surely you'll find > something. I tried using IEEE 1588 without success. In particular I enabled it at build-time of DPDK and then after calling rte_eth_rx_burst() I tried calling rte_eth_timesync_read_tx_timestamp() to get a timestamp from the port_id used to receive a burst of packets, but the function always returns with an error. Moreover, even if the function succeeded I need a timestamp for every incoming packet, not a single timestamp for the whole burst of received packets... do you know how I could achieve that? Thanks, Francesco
[dpdk-dev] Accurate timestamps in received packets
Hi all, I'm using rte_eth_rx_burst() to successfully retrieve packets from a DPDK-enabled port. I can process the packet and everything works fine. My only issue is that I cannot find any mean to retrieve a timestamp for every single packet. As a dirty-workaround I'm using gettimeofday() to timestamp incoming packets but I would rather like to retrieve a more accurate and realistic timestamp from the Ethernet PHY layer instead. For example if I receive 32 packets in a single burst I'm just assigning the packets timestamp with 1ns of difference (using gettimeofday() for the initial time offset). Is there a way to retrieve a realistic timestamp from the Ethernet PHY layer? I found this patch searching on the web: http://www.wand.net.nz/trac/libtrace/browser/Intel%20DPDK%20Patches/hardware_timestamp.patch that is however related to an older DPDK version and works only for INTEL 82580 controllers... do you know if that simple patch linked above could be similarly ported to Intel 82599 and 82571 controllers? Is there any better/easier way to do that? Thanks a lot, Francesco Montorsi
[dpdk-dev] rte_eal_init() alternative?
> > It seems the patch missed the boat :) > > Correct, sorry. I'm attaching it now. Ok, for some reason the email client is removing the attachment... I'm copying and pasting it: (the points marked as TODO are functions that still contain rte_panic() calls...) dpdk-2.1.0/lib/librte_eal/common/eal_common_log.c - dpdk-2.1.0/lib/librte_eal/common/eal_common_log.c dpdk-2.1.0/lib/librte_eal/common/include/rte_eal.h - dpdk-2.1.0/lib/librte_eal/common/include/rte_eal.h --- /tmp/tmp.6220.372015-10-08 16:15:22.402607404 +0200 +++ dpdk-2.1.0/lib/librte_eal/common/include/rte_eal.h 2015-10-08 15:57:21.442627152 +0200 @@ -141,6 +141,9 @@ * returning. See also the rte_eal_get_configuration() function. Note: * This behavior may change in the future. * + * This function will log and eventually abort the entire application if + * initialization fails. + * * @param argc * The argc argument that was given to the main() function. * @param argv @@ -153,6 +156,27 @@ * - On failure, a negative error value. */ int rte_eal_init(int argc, char **argv); + +/** + * Initialize the Environment Abstraction Layer (EAL). + * + * Please refer to rte_eal_init() for more information. + * The difference between rte_eal_init() and rte_eal_init_raw() + * is that the latter will never abort the entire process but rather + * will just log an error and return an error code. + * + * @param logid + * A string that identifies the whole process, used to prefix log messages; + * on Linux will be used as the 'ident' parameter of the syslog facility openlog(). + * @param cfg + * The internal configuration for RTE EAL. + * @return + * - On success, zero. + * - On failure, a negative error value. + */ +struct internal_config; +int rte_eal_init_raw(const char* logid, struct internal_config *cfg); + /** * Usage function typedef used by the application usage function. * dpdk-2.1.0/lib/librte_eal/linuxapp/eal/eal.c - dpdk-2.1.0/lib/librte_eal/linuxapp/eal/eal.c --- /tmp/tmp.6220.752015-10-08 16:15:22.406607404 +0200 +++ dpdk-2.1.0/lib/librte_eal/linuxapp/eal/eal.c2015-10-08 16:15:10.106607628 +0200 @@ -178,7 +178,7 @@ * on other parts, e.g. memzones, to detect if there are running secondary * processes. */ static void -rte_eal_config_create(void) +rte_eal_config_create(void)// TODO { void *rte_mem_cfg_addr; int retval; @@ -232,7 +232,7 @@ /* attach to an existing shared memory config */ static void -rte_eal_config_attach(void) +rte_eal_config_attach(void)// TODO { struct rte_mem_config *mem_config; @@ -258,7 +258,7 @@ /* reattach the shared config at exact memory location primary process has it */ static void -rte_eal_config_reattach(void) +rte_eal_config_reattach(void) // TODO { struct rte_mem_config *mem_config; void *rte_mem_cfg_addr; @@ -305,7 +305,7 @@ /* Sets up rte_config structure with the pointer to shared memory config.*/ static void -rte_config_init(void) +rte_config_init(void) // TODO { rte_config.process_type = internal_config.process_type; @@ -724,25 +724,17 @@ #endif } -/* Launch threads, called at application init(). */ + +/* Launch threads, called at application init(). Logs and aborts on critical errors. */ int rte_eal_init(int argc, char **argv) { - int i, fctret, ret; - pthread_t thread_id; - static rte_atomic32_t run_once = RTE_ATOMIC32_INIT(0); - struct shared_driver *solib = NULL; + int fctret; const char *logid; - char cpuset[RTE_CPU_AFFINITY_STR_LEN]; - - if (!rte_atomic32_test_and_set(_once)) - return -1; logid = strrchr(argv[0], '/'); logid = strdup(logid ? logid + 1: argv[0]); - thread_id = pthread_self(); - if (rte_eal_log_early_init() < 0) rte_panic("Cannot init early logs\n"); @@ -751,18 +743,54 @@ /* set log level as early as possible */ rte_set_log_level(internal_config.log_level); - if (rte_eal_cpu_init() < 0) - rte_panic("Cannot detect lcores\n"); - fctret = eal_parse_args(argc, argv); if (fctret < 0) exit(1); + if (rte_eal_init_raw(logid, NULL) < 0) + rte_panic("Errors encountered during initialization. Cannot proceed.\n"); + + return fctret; +} + +/* Library-style init(), will attempt initialization, log on errors and return; + * This function does not rte_panic() or exit() the whole process. */ +int +rte_eal_init_raw(const char* logid, struct internal_config *cfg) +{ + int i, ret; + pthread_t thread_id; + static rte_atomic32_t run_once = RTE_ATOMIC32_INIT(0); + struct shared_driver *solib = NULL; + char cpuset[RTE_CPU_AFFINITY_STR_LEN]; + + if (!rte_atomic32_test_and_set(_once)) + return -1; + + thread_id = pthread_self(); + if
[dpdk-dev] rte_eal_init() alternative?
Hi Panu, > -Original Message- > From: Panu Matilainen [mailto:pmatilai at redhat.com] > Sent: venerd? 9 ottobre 2015 10:26 > To: Montorsi, Francesco ; Thomas Monjalon > > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] rte_eal_init() alternative? > > > Something like the attached patch. > > It seems the patch missed the boat :) Correct, sorry. I'm attaching it now. > > > Note that the attached patch exposes also a way to skip the argv/argc > > configuration process by directly providing a populated configuration > > structure... > > Let me know what you think about it (the patch is just a draft and > > needs more work). > > Can't comment on what I've not seen, but based on comments seen on this > list, having an alternative way to initialize with structures would be > welcomed > by many. The downside is that those structures will need to be exposed in > the API forever which means any changes there are subject to the ABI > process. > Perhaps the init function taking a structure could be an exception for ABI changes... i.e., the format of the configuration is not garantueed to stay the same between different versions, and applications using a shared build of DPDK libraries must avoid using the configuration structure... would that be a possible solution? Thanks, Francesco
[dpdk-dev] rte_eal_init() alternative?
Hi, > -Original Message- > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > Sent: mercoled? 2 settembre 2015 15:10 > To: Montorsi, Francesco > Cc: dev at dpdk.org; Bruce Richardson > Subject: Re: [dpdk-dev] rte_eal_init() alternative? > > 2015-09-02 13:56, Bruce Richardson: > > On Wed, Sep 02, 2015 at 12:49:40PM +, Montorsi, Francesco wrote: > > > Hi all, > > > > > > Currently it seems that the only way to initialize EAL is using > > > rte_eal_init() > function, correct? > > > > > > I have the problem that rte_eal_init() will call rte_panic() whenever > something fails to initialize or in other cases it will call exit(). > > > In my application, I would rather like to attempt DPDK initialization. If > > > it > fails I don't want to exit. > > > Unfortunately I cannot even copy the rte_eal_init() code into my > application (removing rte_panic and exit calls) since it uses a lot of DPDK > internal private functions. > > > > > > I think that my requirements (avoid abort/exit calls when init fails) is a > basic requirement... would you accept a patch that adds an alternative > rte_eal_init() function that just returns an error code upon failure, instead > of > immediately exiting? > > > > > > Thanks for your hard work! > > > > > > Francesco Montorsi > > > > > I, for one, would welcome such a patch. I think the code is overly > > quick in many places to panic or exit the app, when an error code would be > more appropriate. > > Feel free to also look at other libraries in DPDK too, if you like :-) > > Yes but please, do not create an alternative init function. > We just need to replace panic/exit with error codes and be sure that apps > and examples handle them correctly. To maintain compatibility with existing applications I think that perhaps the best would be to have a core initialization function rte_eal_init_raw() that never calls rte_panic() and returns an error code. Then we can maintain compatibility having an rte_eal_init() function that does call rte_panic() if rte_eal_init_raw() fails. Something like the attached patch. Note that the attached patch exposes also a way to skip the argv/argc configuration process by directly providing a populated configuration structure... Let me know what you think about it (the patch is just a draft and needs more work). Thanks, Francesco
[dpdk-dev] "cannot use T= with gcov target" when doing "makefile clean" with DPDK-2.1.0
Hi Olivier, Sorry for the delay: > -Original Message- > From: Olivier MATZ [mailto:olivier.matz at 6wind.com] > I had a look to your test case, I think the second command is not correct. The > T= parameter is not allowed for the clean target. It should be something like > this: > > # configure a workspace using template specified by T= in the > # directory specified by O= > make T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc config > > # clean the directory specified by O= > make O=x86_64-native-linuxapp-gcc clean > > See "make help" for details. > > > I think the proper patch would be to add the following lines on the top of > rte.sdkbuild.mk: > > ifdef T > ifeq ("$(origin T)", "command line") > $(error "Cannot use T= with a build/clean target") > endif > endif > > > It would then display the proper error message. > Can you have a try? You're right. It was not clear to me that T= is coinceived as option of the "config" target only, but it makes absolutely sense. I added the code you posted on ret.sdkbuild.mk and it works just fine, making this usage case more clear... I just submitted a patch for that. Thanks, Francesco
[dpdk-dev] "cannot use T= with gcov target" when doing "makefile clean" with DPDK-2.1.0
Hi John, > -Original Message- > From: Mcnamara, John [mailto:john.mcnamara at intel.com] > Sent: mercoled? 2 settembre 2015 16:32 > To: Montorsi, Francesco ; dev at dpdk.org > Subject: RE: "cannot use T= with gcov target" when doing "makefile clean" > with DPDK-2.1.0 >... > That fix seems reasonable and you should submit it as a patch. > > There may be other ways to fix this (there are several ways to fix things > within the build system) but if you submit a patch we can get some > comments. I will submit the patch ASAP (together with a few others). I guess I need to follow closely what's written here: http://dpdk.org/dev Thanks, Francesco
[dpdk-dev] rte_eal_init() alternative?
Hi all, Currently it seems that the only way to initialize EAL is using rte_eal_init() function, correct? I have the problem that rte_eal_init() will call rte_panic() whenever something fails to initialize or in other cases it will call exit(). In my application, I would rather like to attempt DPDK initialization. If it fails I don't want to exit. Unfortunately I cannot even copy the rte_eal_init() code into my application (removing rte_panic and exit calls) since it uses a lot of DPDK internal private functions. I think that my requirements (avoid abort/exit calls when init fails) is a basic requirement... would you accept a patch that adds an alternative rte_eal_init() function that just returns an error code upon failure, instead of immediately exiting? Thanks for your hard work! Francesco Montorsi
[dpdk-dev] about new timesync feature in 2.1.0
Hi, I'm very interested in getting accurate timestamps for received packets. What is the best way to do it? I found here: http://www.wand.net.nz/trac/libtrace/browser/Intel%20DPDK%20Patches/ some patch to enable timestamping but only on e1000 driver (and honestly I don't know if that patch works with latest DPDK version!) I have tried using the timesync feature of DPDK 2.1.0 but I never get valid RX timestamp: in my app using DPDK I call rte_eth_timesync_enable() at config time and then later when a packet arrives I call rte_eth_timesync_read_tx_timestamp(). Here's what I get: Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: PCI memory mapped at 0x7fff8008 Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: PCI memory mapped at 0x7fff8010 Aug 28 11:07:48 MSP101 HwEmul[19774]: PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 18, SFP+: 5 Aug 28 11:07:48 MSP101 HwEmul[19774]: PMD: eth_ixgbe_dev_init(): port 2 vendorID=0x8086 deviceID=0x10fb Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: PCI device :86:00.1 on NUMA socket 1 Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: probe driver: 8086:10fb rte_ixgbe_pmd Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: PCI memory mapped at 0x7fff80104000 Aug 28 11:07:48 MSP101 HwEmul[19774]: EAL: PCI memory mapped at 0x7fff80184000 Aug 28 11:07:48 MSP101 HwEmul[19774]: PMD: eth_ixgbe_dev_init(): MAC: 2, PHY: 15, SFP+: 10 Aug 28 11:07:48 MSP101 HwEmul[19774]: PMD: eth_ixgbe_dev_init(): port 3 vendorID=0x8086 deviceID=0x10fb Aug 28 11:07:51 MSP101 HwEmul[19774]: PMD: eth_em_rx_queue_setup(): sw_ring=0x7fff62f9cfc0 hw_ring=0x7fff62f9d4c0 dma_addr=0x17a2f9d4c0 Aug 28 11:07:51 MSP101 HwEmul[19774]: PMD: eth_em_tx_queue_setup(): sw_ring=0x7fff62f8ca80 hw_ring=0x7fff62f8cf80 dma_addr=0x17a2f8cf80 Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: eth_em_start(): << Aug 28 11:07:52 MSP101 HwEmul[19774]: ERROR HwEmulCaptureDPDK::init() rte_eth_timesync_enable:err=-95, port=0: Unknown error -95 Aug 28 11:07:52 MSP101 HwEmul[19774]: ALERT HwEmulCaptureDPDK::init() Initializing port 1... Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: eth_em_rx_queue_setup(): sw_ring=0x7fff62f7c440 hw_ring=0x7fff62f7c940 dma_addr=0x17a2f7c940 Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: eth_em_tx_queue_setup(): sw_ring=0x7fff62f6bf00 hw_ring=0x7fff62f6c400 dma_addr=0x17a2f6c400 Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: eth_em_start(): << Aug 28 11:07:52 MSP101 HwEmul[19774]: ERROR HwEmulCaptureDPDK::init() rte_eth_timesync_enable:err=-95, port=1: Unknown error -95 Aug 28 11:07:52 MSP101 HwEmul[19774]: ALERT HwEmulCaptureDPDK::init() Initializing port 2... Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7ffebffef6c0 sw_sc_ring=0x7ffebffef180 hw_ring=0x7ffebffefc00 dma_addr=0x2fbffefc00 Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7ffebffdebc0 hw_ring=0x7ffebffdf000 dma_addr=0x2fbffdf000 Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: ixgbe_set_tx_function(): Using simple tx code path Aug 28 11:07:52 MSP101 HwEmul[19774]: PMD: ixgbe_set_tx_function(): Vector tx enabled. Aug 28 11:09:06 MSP101 HwEmul[19774]: PMD: ixgbe_set_rx_function(): Port[2] doesn't meet Vector Rx preconditions or RTE_IXGBE_INC_VECTOR is not enabled Aug 28 11:09:06 MSP101 HwEmul[19774]: PMD: ixgbe_set_rx_function(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=2. Aug 28 11:09:07 MSP101 HwEmul[19774]: PMD: ixgbe_dev_rx_queue_setup(): sw_ring=0x7ffebffce2c0 sw_sc_ring=0x7ffebffcdd80 hw_ring=0x7ffebffce800 dma_addr=0x2fbffce800 Aug 28 11:09:07 MSP101 HwEmul[19774]: PMD: ixgbe_dev_tx_queue_setup(): sw_ring=0x7ffebffbd7c0 hw_ring=0x7ffebffbdc00 dma_addr=0x2fbffbdc00 Aug 28 11:09:07 MSP101 HwEmul[19774]: PMD: ixgbe_set_tx_function(): Using simple tx code path Aug 28 11:09:07 MSP101 HwEmul[19774]: PMD: ixgbe_set_tx_function(): Vector tx enabled. Aug 28 11:09:09 MSP101 HwEmul[19774]: PMD: ixgbe_set_rx_function(): Port[3] doesn't meet Vector Rx preconditions or RTE_IXGBE_INC_VECTOR is not enabled Aug 28 11:09:09 MSP101 HwEmul[19774]: PMD: ixgbe_set_rx_function(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=3. Here rte_eth_timesync_enable() failed on 2 ports (they are 1G Intel ports) and is successful on other 2 ports. But then when I send 1 packet on the port with timesync enabled I get an error from rte_eth_timesync_read_tx_timestamp(): Aug 28 13:23:18 MSP101 HwEmul[25381]: [25416] ERROR Port 3 RX timestamp registers not valid: -22 Does the port need IEEE1588 messages in order to setup its timestamp registers? Can I use IEEE1588 to just get some timestamp from the NIC (ideally, I would like to have 1timestamp for each received packet)? Thanks a lot, Francesco Montorsi
[dpdk-dev] "cannot use T= with gcov target" when doing "makefile clean" with DPDK-2.1.0
Hi all, I found that after unzipping dpdk-2.1.0.tar.gz if I run: # make T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc config And then # make V=1 T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc clean I get: [...] == Clean app/proc_info make -f /home/fmontorsi/Downloads/dpdk-2.1.0/GNUmakefile gcovclean make -f /home/fmontorsi/Downloads/dpdk-2.1.0/mk/rte.sdkgcov.mk gcovclean /home/fmontorsi/Downloads/dpdk-2.1.0/mk/rte.sdkgcov.mk:34: *** "Cannot use T= with gcov target". Stop. make[2]: *** [gcovclean] Error 2 make[1]: *** [clean] Error 2 make: *** [clean] Error 2 I guess the fix is: --- /home/fmontorsi/Downloads/dpdk-2.1.0/mk/rte.sdkbuild.mk 2015-08-17 19:35:37.0 +0200 +++ dpdk-2.1.0/mk/rte.sdkbuild.mk 2015-08-28 10:52:56.092466418 +0200 @@ -85,5 +85,7 @@ @$(RTE_SDK)/scripts/gen-config-h.sh $(RTE_OUTPUT)/.config \ > $(RTE_OUTPUT)/include/rte_config.h +ifndef T $(Q)$(MAKE) -f $(RTE_SDK)/GNUmakefile gcovclean +endif @echo Clean complete Let me know if the patch above is wrong or I should do something else to contribute it to the project in the right way. Thanks, Francesco Montorsi
[dpdk-dev] how to build dpdk in debug mode?
Hi all, I have searched the archives for this, without much success. Is it possible to build dpdk user-space libraries with -O0 and -g instead of -O3 ? This would make debugging via GDB much more friendly... Thanks! Francesco Montorsi
[dpdk-dev] conflict between ether_addr defined in rte_ether.h and the same structure in
Hi all, I 'm attempting to integrate DPDK code in an existing application, which includes . That standard glibc header already provides a structure named ether_addr defined as: struct ether_addr { u_int8_t ether_addr_octet[ETH_ALEN]; } __attribute__ ((__packed__)); So the result is that gcc complains about the redefinition: dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:55:0: warning: "ETHER_ADDR_LEN" redefined [enabled by default] /opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:60:0: note: this is the location of the previous definition dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:58:0: warning: "ETHER_HDR_LEN" redefined [enabled by default] /opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:63:0: note: this is the location of the previous definition dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:60:0: warning: "ETHER_MIN_LEN" redefined [enabled by default] /opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:64:0: note: this is the location of the previous definition dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:61:0: warning: "ETHER_MAX_LEN" redefined [enabled by default] /opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:65:0: note: this is the location of the previous definition dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:86:8: error: redefinition of 'struct ether_addr' /opt/empirix/toolchains/x86_64-gcc-4.6.1-glibc-2.14-1.0-6/tools/include/net/ethernet.h:33:8: error: previous definition of 'struct ether_addr' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_same_ether_addr(const ether_addr*, const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:112:12: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:112:34: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_zero_ether_addr(const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:131:11: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_unicast_ether_addr(const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:148:15: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_multicast_ether_addr(const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:163:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_universal_ether_addr(const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:196:15: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'int is_local_admin_ether_addr(const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:211:15: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h: In function 'void ether_format_addr(char*, uint16_t, const ether_addr*)': dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:288:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:289:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:290:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:291:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:292:14: error: 'const struct ether_addr' has no member named 'addr_bytes' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/include/rte_ether.h:293:14: error: 'const struct ether_addr' has no member named 'addr_bytes' My idea here is that DPDK should rather define an "rte_ether_addr" (or directly always use but I guess this is not done for some good reason)... isn't it? Thanks, Francesco Montorsi
[dpdk-dev] how to compile kernel drivers only
Hi Thomas, Thanks for your reply. My problem is that I have in app/Makefile: DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += dump_cfg So that I should put CONFIG_RTE_LIBRTE_EAL_LINUXAPP=n To disable dump_cfg application build. However, If I do so, the kernel drivers are not built at all and make just says: make T=x86_64-native-linuxapp-gcc O=x86_64-native-linuxapp-gcc EXTRA_LDFLAGS="" --directory=dpdk-2.0.0 all make[1]: Entering directory `/home/hammer/share/CSA-Hamachi-Sprint/HW-Accel/drivers/dpdk/dpdk-2.0.0' == Build lib == Build lib/librte_compat SYMLINK-FILE include/rte_compat.h == Build lib/librte_eal == Build app Build complete So that CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y Seems to be a pre-requisite of kernel drivers... or am I missing something? Thanks, Francesco -Original Message- From: Thomas Monjalon [mailto:thomas.monja...@6wind.com] Sent: gioved? 30 luglio 2015 14:23 To: Montorsi, Francesco Cc: dev at dpdk.org Subject: Re: [dpdk-dev] how to compile kernel drivers only 2015-07-30 12:17, Montorsi, Francesco: > How can I avoid building any app like dump_cfg? In app/Makefile, you'll find the options to disable: DIRS-$(CONFIG_RTE_APP_TEST) += test DIRS-$(CONFIG_RTE_LIBRTE_ACL) += test-acl DIRS-$(CONFIG_RTE_LIBRTE_PIPELINE) += test-pipeline DIRS-$(CONFIG_RTE_TEST_PMD) += test-pmd DIRS-$(CONFIG_RTE_LIBRTE_CMDLINE) += cmdline_test DIRS-$(CONFIG_RTE_LIBRTE_EAL_LINUXAPP) += proc_info
[dpdk-dev] how to compile kernel drivers only
Hi all, I'm trying to compile DPDK kernel drivers (i.e., igb_uio.ko and kni.ko if I got it right) only on a certain machine. On that machine, I'm not interested in anything else. how can I tweak .config file to achieve it? I have tried to set all options to =n, except for: CONFIG_RTE_LIBRTE_EAL=y CONFIG_RTE_LIBRTE_EAL_LINUXAPP=y CONFIG_RTE_EAL_IGB_UIO=y CONFIG_RTE_EAL_VFIO=y CONFIG_RTE_LIBRTE_KNI=y But then I get a compile error about app/dump_cfg: == Build app/dump_cfg ? CC main.o ? LD dump_cfg dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_common_log.o): In function `rte_eal_common_log_init': eal_common_log.c:(.text+0x1b0): undefined reference to `rte_mempool_create' eal_common_log.c:(.text+0x1fe): undefined reference to `rte_mempool_lookup' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_pci_uio.o): In function `pci_uio_map_resource': eal_pci_uio.c:(.text+0x4dd): undefined reference to `rte_zmalloc' eal_pci_uio.c:(.text+0x873): undefined reference to `rte_malloc' eal_pci_uio.c:(.text+0x9bf): undefined reference to `rte_malloc' eal_pci_uio.c:(.text+0xb0a): undefined reference to `rte_malloc' eal_pci_uio.c:(.text+0xc55): undefined reference to `rte_malloc' eal_pci_uio.c:(.text+0xda6): undefined reference to `rte_malloc' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_pci_uio.o):eal_pci_uio.c:(.text+0xf00): more undefined references to `rte_malloc' follow dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_pci_uio.o): In function `pci_uio_map_resource': eal_pci_uio.c:(.text+0x10e4): undefined reference to `rte_free' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_interrupts.o): In function `rte_intr_callback_unregister': eal_interrupts.c:(.text+0x7b6): undefined reference to `rte_free' eal_interrupts.c:(.text+0x7f2): undefined reference to `rte_free' eal_interrupts.c:(.text+0x84c): undefined reference to `rte_free' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_interrupts.o): In function `rte_intr_callback_register': eal_interrupts.c:(.text+0x8fb): undefined reference to `rte_zmalloc' eal_interrupts.c:(.text+0x96f): undefined reference to `rte_zmalloc' eal_interrupts.c:(.text+0xac4): undefined reference to `rte_free' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In function `rte_eal_alarm_cancel': eal_alarm.c:(.text+0xa4): undefined reference to `rte_free' eal_alarm.c:(.text+0x128): undefined reference to `rte_free' eal_alarm.c:(.text+0x156): undefined reference to `rte_free' eal_alarm.c:(.text+0x1d3): undefined reference to `rte_free' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In function `rte_eal_alarm_set': eal_alarm.c:(.text+0x31e): undefined reference to `rte_zmalloc' dpdk/dpdk-2.0.0/x86_64-native-linuxapp-gcc/lib/librte_eal.a(eal_alarm.o): In function `eal_alarm_callback': eal_alarm.c:(.text+0x59e): undefined reference to `rte_free' How can I avoid building any app like dump_cfg? Thanks! Francesco