[dpdk-dev] rte_ixgbevf_pmd not reporting dropped packets

[Montorsi, Francesco]

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?

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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 Montorsi 
Date: 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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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...

[Montorsi, Francesco]

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...

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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?

[Montorsi, Francesco]

> > 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?

[Montorsi, Francesco]

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?

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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?

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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?

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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

[Montorsi, Francesco]

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