[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
On 16 February 2016 at 19:47, Matthew Hall wrote: > On Tue, Feb 16, 2016 at 12:57:24PM +, De Lara Guarch, Pablo wrote: > > We suspect this might be an architecture dependent issue. > > Could you tell us which CPU you are using? > > > > Thanks, > > Pablo > > When it happens to me I am using a Skylake Core i7-6700K. > Broadwell qemu emulated. Marc > > Matthew. >
[dpdk-dev] rte_lcore_to_socket_id(lcore_id) mismatches to that of lstopo
I printed cpu layout with cpu_layout.py tool in dpdk tools directory and lstopo linux command. They shows the same result that my lcore 0, 2, 4, and 6 are in socket #1. However, rte_lcore_to_socket_id() returns 0 for lcore 0, 2, 4, and 6. Why does this difference occur and which value should I use to match lcore to socket? (i.e. I'm using dpdk 2.2.0 on Xeon E5520 that is based on nehalem microarchitecture.) [mslee at centos7 tools]$ ./cpu_layout.py Core and Socket Information (as reported by '/proc/cpuinfo') cores = [0, 1, 2, 3] sockets = [1, 0] Socket 1Socket 0 Core 0 [0, 8] [1, 9] Core 1 [2, 10] [3, 11] Core 2 [4, 12] [5, 13] Core 3 [6, 14] [7, 15] code fragment: socketid = rte_lcore_to_socket_id(lcore_id); RTE_LOG(INFO, APP, "init_mem: lcore_id = %d, socketid = %d\n", lcore_id, socketid); log fragment: APP: init_mem: lcore_id = 0, socketid = 0 APP: init_mem: lcore_id = 2, socketid = 0 APP: init_mem: lcore_id = 4, socketid = 0 APP: init_mem: lcore_id = 6, socketid = 0 -- Moon-Sang Lee, SW Engineer Email: sang0627 at gmail.com Wisdom begins in wonder. *Socrates*
[dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
From: Ziye The purpose of this patch is used to add a new field "class" in rte_pci_id structure. The new class field includes class_id, subcalss_id, programming interface of a pci device. With this field, we can identify pci device by its class info, which can be more flexible instead of probing the device by vendor_id OR device_id OR subvendor_id OR subdevice_id. For example, we can probe all nvme devices by class field, which can be quite convenient. Signed-off-by: Ziye Yang --- doc/guides/rel_notes/deprecation.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index e94d4a2..9fa2433 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -49,3 +49,9 @@ Deprecation Notices commands (such as RETA update in testpmd). This should impact CMDLINE_PARSE_RESULT_BUFSIZE, STR_TOKEN_SIZE and RDLINE_BUF_SIZE. It should be integrated in release 2.3. + +* ABI changes are planned for struct rte_pci_id, i.e., add new field ``class``. + This new added ``class`` field can be used to probe pci device by class + related info. This change should impact size of struct rte_pci_id and struct + rte_pci_device. The release 16.04 does not contain these ABI changes, but + release 16.07 will. -- 1.9.3
[dpdk-dev] [PATCH v2 2/5] EAL: Add new EAL "--qtest-virtio" option
On 2016/02/16 20:36, Tan, Jianfeng wrote:
> Hi David,
>
> On 2/16/2016 1:53 PM, David Marchand wrote:
>> On Wed, Feb 10, 2016 at 4:40 AM, Tetsuya Mukawa
>> wrote:
>>> To work with qtest virtio-net PMD, virtual address that maps hugepages
>>> should be between (1 << 31) to (1 << 44). This patch adds one more
>>> option
>>> to map like this. Also all hugepages should consists of one file.
>>> Because of this, the option will work only when '--single-file'
>>> option is
>>> specified.
>> This patch is pure virtio stuff.
>> Please, rework this so that we have a generic api in eal (asking for a
>> free region could be of use for something else).
>> Then you can call this api from virtio pmd.
>>
>> If you need to pass options to virtio pmd, add some devargs for it.
>>
>
> Seems it's hard to slip this option into --vdev="eth_qtest_virtio0..."
> from my side because memory initialization happens before vdev option
> is parsed.
>
> Can we make use of "--base-virtaddr" achieve the function of this option?
I think same thing also.
Option1 is just using "--base-virtaddr" option without any fixes.
Option2 is adding "--range-virtaddr" option.
When "--range-option" is set, EAL will find free region in specified
memory region, then set the address to 'base_vrtiaddr' variable.
This will be done before base_addr variable is used by current
implementation.
How about this?
Here is rough implementation.
diff --git a/lib/librte_eal/common/eal_common_options.c
b/lib/librte_eal/common/eal_common_options.c
index 65bccbd..996b61d 100644
--- a/lib/librte_eal/common/eal_common_options.c
+++ b/lib/librte_eal/common/eal_common_options.c
@@ -74,6 +74,8 @@ eal_short_options[] =
const struct option
eal_long_options[] = {
{OPT_BASE_VIRTADDR, 1, NULL, OPT_BASE_VIRTADDR_NUM},
+ {OPT_RANGE_VIRTADDR,1, NULL, OPT_RANGE_VIRTADDR_NUM },
+ {OPT_ALIGN_MEMSIZE, 0, NULL, OPT_ALIGN_MEMSIZE_NUM},
{OPT_CREATE_UIO_DEV,0, NULL, OPT_CREATE_UIO_DEV_NUM },
{OPT_FILE_PREFIX, 1, NULL, OPT_FILE_PREFIX_NUM },
{OPT_HELP, 0, NULL, OPT_HELP_NUM },
@@ -137,6 +139,9 @@ eal_reset_internal_config(struct internal_config
*internal_cfg)
for (i = 0; i < MAX_HUGEPAGE_SIZES; i++)
internal_cfg->hugepage_info[i].lock_descriptor = -1;
internal_cfg->base_virtaddr = 0;
+ internal_cfg->range_virtaddr_start = 0;
+ internal_cfg->range_virtaddr_end = 0;
+ internal_cfg->align_memsize = 0;
internal_cfg->syslog_facility = LOG_DAEMON;
/* default value from build option */
@@ -985,6 +990,18 @@ eal_check_common_options(struct internal_config
*internal_cfg)
return -1;
}
+ if (internal_cfg->base_virtaddr &&
internal_cfg->range_virtaddr_end) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_RANGE_VIRTADDR" cannot "
+ "be specified together with
--"OPT_BASE_VIRTADDR"\n");
+ return -1;
+ }
+
+ if (internal_cfg->range_virtaddr_end !=0 &&
internal_cfg->align_memsize) {
+ RTE_LOG(ERR, EAL, "Option --"OPT_RANGE_VIRTADDR" should be "
+ "specified together with --"OPT_ALIGN_MEMSIZE"\n");
+ return -1;
+ }
+
return 0;
}
diff --git a/lib/librte_eal/common/eal_internal_cfg.h
b/lib/librte_eal/common/eal_internal_cfg.h
index 9117ed9..df33a9f 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -78,6 +78,9 @@ struct internal_config {
volatile unsigned force_sockets;
volatile uint64_t socket_mem[RTE_MAX_NUMA_NODES]; /**< amount of
memory per socket */
uintptr_t base_virtaddr; /**< base address to try and
reserve memory from */
+ uintptr_t range_virtaddr_start; /**< start address of mappable
region */
+ uintptr_t range_virtaddr_end; /**< end address of mappable
region */
+ volatile unsigned align_memsize; /**< true to align virtaddr by
memory size */
volatile int syslog_facility; /**< facility passed to
openlog() */
volatile uint32_t log_level; /**< default log level */
/** default interrupt mode for VFIO */
diff --git a/lib/librte_eal/common/eal_options.h
b/lib/librte_eal/common/eal_options.h
index e5da14a..9e36f68 100644
--- a/lib/librte_eal/common/eal_options.h
+++ b/lib/librte_eal/common/eal_options.h
@@ -47,6 +47,10 @@ enum {
OPT_LONG_MIN_NUM = 256,
#define OPT_BASE_VIRTADDR "base-virtaddr"
OPT_BASE_VIRTADDR_NUM,
+#define OPT_RANGE_VIRTADDR"range-virtaddr"
+ OPT_RANGE_VIRTADDR_NUM,
+#define OPT_ALIGN_MEMSIZE "align-memsize"
+ OPT_ALIGN_MEMSIZE_NUM,
#define OPT_CREATE_UIO_DEV"create-uio-dev"
OPT_CREATE_UIO_DEV_NUM,
#define OPT_FILE_PREFIX "file-prefix"
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 82f34f7..e6c6b34 100644
--- a/lib/librte_eal
[dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX checksum off-load
Hi Konstantin, > -Original Message- > From: Ananyev, Konstantin > Sent: Monday, February 15, 2016 9:16 PM > To: Thomas Monjalon; Lu, Wenzhuo > Cc: dev at dpdk.org > Subject: RE: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX > checksum off-load > > Hi lads, > > > -Original Message- > > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com] > > Sent: Monday, February 15, 2016 10:03 AM > > To: Lu, Wenzhuo > > Cc: dev at dpdk.org; Ananyev, Konstantin > > Subject: Re: [dpdk-dev] [PATCH v2 5/6] ixgbe: support VxLAN & NVGRE TX > > checksum off-load > > > > 2016-02-15 05:32, Lu, Wenzhuo: > > > From: Ananyev, Konstantin > > > > From reading X550 spec, I don't really understand what for we need > > > > to specify is it GRE or VXLAN packet, so probably we don't need that > > > > flag > for now at all? > > > The reason is we need to set the tunnel type in the Advanced Transmit Data > Descriptor. > > Yes, I saw that in x550 spec, though I really doubt it is needed to calculate > etiher > outer IP, or inner IP/L4 checksum. > After all TUNNELLEN includes all tunnel headers plus inner L2 length. > The only reason I can think it might be useful for HW is when packets are > sent > from one VF to another. > In that case, HW probably would try to avoid extra packet scanning and rely on > information from SW. > As mentioned in x550 spec, section's note: > "...In virtualization mode, packets might be received from other local VMs. > The > X550 does not check the L5 header for these packets and does not report NFS > header. If such packets carry IP tunneling (IPv4 - IPv6), they are reported as > IPV4E. The packets received from local VM are indicated by the LB bit in the > status field. To be identified, the CC bit in the transmit descriptor must be > set > and if it is a tunnel packet, the TUNNEL.OUTERIPCS must be set also." > Though I am not sure we do need to support that case. > That's why probably the easiest way would be to avoid setting 'Tunnel Type' > field > at all. Many thanks for your suggestion. I think you're right. For outer IP header checksum offload, we need not to set the tunnel type bit. I'll choose this option and remove this vxlan ol_flag. > > > > > Why don't we use packet type? > > Yes, that's probably another possible way, if we really decide to setup this > info > at TX descriptor. > > BTW, reading x550 spec, I think ixgbe RX code that setups packet_type need to > be updated too. > Right now it can't handle vxlan/gre tunnelling case. > > Konstantin > > > > > > > If we really do, might bw worth to organise it like KT_TX_L4_CKSUM > > > > (as enum) and reserve few values for future expansion (2 or 3 bits?). > > > Now there're only VxLAN and NVGRE supported. So, only 1 bit is > > > occupied for that. Not sure if more types will be supported in the > > future. Any suggestions? Thanks. > > > > Yes there can be a lot of tunnel types. > > Please check RTE_PTYPE_TUNNEL_* > >
[dpdk-dev] [PATCH v2 3/3] examples/vmdq_dcb: extend sample for X710 supporting
Currently, the example vmdq_dcb only works on Intel(R) 82599 NICs. This patch extended this sample to make it work both on Intel(R) 82599 and X710/XL710 NICs by following changes: 1. add VMDQ base queue checking to avoid forwarding on PF queues. 2. assign each VMDQ pools with MAC address. 3. add more arguments (nb-tcs, enable-rss) to change the default setting 4. extend the max number of queues from 128 to 1024. This patch also reworked the user guide for the vmdq_dcb sample. Signed-off-by: Jingjing Wu --- doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 171 ++ examples/vmdq_dcb/main.c | 390 ++- 2 files changed, 430 insertions(+), 131 deletions(-) diff --git a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst index 9140a22..305636b 100644 --- a/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst +++ b/doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst @@ -32,8 +32,8 @@ VMDQ and DCB Forwarding Sample Application == The VMDQ and DCB Forwarding sample application is a simple example of packet processing using the DPDK. -The application performs L2 forwarding using VMDQ and DCB to divide the incoming traffic into 128 queues. -The traffic splitting is performed in hardware by the VMDQ and DCB features of the Intel? 82599 10 Gigabit Ethernet Controller. +The application performs L2 forwarding using VMDQ and DCB to divide the incoming traffic into queues. +The traffic splitting is performed in hardware by the VMDQ and DCB features of the Intel? 82599 and X710/XL710 Ethernet Controllers. Overview @@ -41,28 +41,27 @@ Overview This sample application can be used as a starting point for developing a new application that is based on the DPDK and uses VMDQ and DCB for traffic partitioning. -The VMDQ and DCB filters work on VLAN traffic to divide the traffic into 128 input queues on the basis of the VLAN ID field and -VLAN user priority field. -VMDQ filters split the traffic into 16 or 32 groups based on the VLAN ID. -Then, DCB places each packet into one of either 4 or 8 queues within that group, based upon the VLAN user priority field. - -In either case, 16 groups of 8 queues, or 32 groups of 4 queues, the traffic can be split into 128 hardware queues on the NIC, -each of which can be polled individually by a DPDK application. +The VMDQ and DCB filters work on MAC and VLAN traffic to divide the traffic into input queues on the basis of the Destination MAC +address, VLAN ID and VLAN user priority fields. +VMDQ filters split the traffic into 16 or 32 groups based on the Destination MAC and VLAN ID. +Then, DCB places each packet into one of queues within that group, based upon the VLAN user priority field. All traffic is read from a single incoming port (port 0) and output on port 1, without any processing being performed. -The traffic is split into 128 queues on input, where each thread of the application reads from multiple queues. -For example, when run with 8 threads, that is, with the -c FF option, each thread receives and forwards packets from 16 queues. +With Intel? 82599 NIC, for example, the traffic is split into 128 queues on input, where each thread of the application reads from +multiple queues. When run with 8 threads, that is, with the -c FF option, each thread receives and forwards packets from 16 queues. -As supplied, the sample application configures the VMDQ feature to have 16 pools with 8 queues each as indicated in :numref:`figure_vmdq_dcb_example`. -The Intel? 82599 10 Gigabit Ethernet Controller NIC also supports the splitting of traffic into 32 pools of 4 queues each and -this can be used by changing the NUM_POOLS parameter in the supplied code. -The NUM_POOLS parameter can be passed on the command line, after the EAL parameters: +As supplied, the sample application configures the VMDQ feature to have 32 pools with 4 queues each as indicated in :numref:`figure_vmdq_dcb_example`. +The Intel? 82599 10 Gigabit Ethernet Controller NIC also supports the splitting of traffic into 16 pools of 8 queues. While the +Intel? X710 or XL710 Ethernet Controller NICs support many configurations of VMDQ pools of 4 or 8 queues each. For simplicity, only 16 +or 32 pools is supported in this sample. And queues numbers for each VMDQ pool can be changed by setting CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM +in config/common_* file. +The nb-pools, nb-tcs and enable-rss parameters can be passed on the command line, after the EAL parameters: .. code-block:: console -./build/vmdq_dcb [EAL options] -- -p PORTMASK --nb-pools NP +./build/vmdq_dcb [EAL options] -- -p PORTMASK --nb-pools NP --nb-tcs TC --enable-rss -where, NP can be 16 or 32. +where, NP can be 16 or 32, TC can be 4 or 8, rss is disabled by default. .. _figure_vmdq_dcb_example: @@ -72,9 +71,7 @@ where, NP can be 16 or 32. In Linux* user space, th
[dpdk-dev] [PATCH v2 0/3] extend vmdq_dcb sample for X710 supporting
Currently, the example vmdq_dcb only works on Intel(R) 82599 NICs. This patchset extended this sample to make it works both on Intel(R) 82599 and X710/XL710 NICs. This patch set also enabled DCB VMDQ mode in i40e driver and added unsupported mode checking in ixgbe driver. v2 changes: - commit log doc rewording. - rebase on latest dpdk-next-net/rel_16_04 branch. - code style fix Jingjing Wu (3): i40e: enable DCB in VMDQ VSIs ixgbe: disallow unsupported RX mode examples/vmdq_dcb: extend sample for X710 supporting doc/guides/rel_notes/release_16_04.rst | 3 + doc/guides/sample_app_ug/vmdq_dcb_forwarding.rst | 171 ++ drivers/net/i40e/i40e_ethdev.c | 153 +++-- drivers/net/i40e/i40e_ethdev.h | 28 +- drivers/net/ixgbe/ixgbe_ethdev.c | 5 + examples/vmdq_dcb/main.c | 390 ++- 6 files changed, 587 insertions(+), 163 deletions(-) -- 2.4.0
[dpdk-dev] [PATCH v2 1/3] i40e: enable DCB in VMDQ VSIs
Previously, DCB(Data Center Bridging) is only enabled on PF,
queue mapping and BW configuration is only done on PF.
This patch enabled DCB for VMDQ VSIs(Virtual Station Interfaces)
by following steps:
1. Take BW and ETS(Enhanced Transmission Selection)
configuration on VEB(Virtual Ethernet Bridge).
2. Take BW and ETS configuration on VMDQ VSIs.
3. Update TC(Traffic Class) and queues mapping on VMDQ VSIs.
To enable DCB on VMDQ, the number of TCs should not be lager than
the number of queues in VMDQ pools, and the number of queues per
VMDQ pool is specified by CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM
in config/common_* file.
Signed-off-by: Jingjing Wu
---
doc/guides/rel_notes/release_16_04.rst | 3 +
drivers/net/i40e/i40e_ethdev.c | 153 +
drivers/net/i40e/i40e_ethdev.h | 28 +++---
3 files changed, 152 insertions(+), 32 deletions(-)
diff --git a/doc/guides/rel_notes/release_16_04.rst
b/doc/guides/rel_notes/release_16_04.rst
index 81f62f1..d3b035c 100644
--- a/doc/guides/rel_notes/release_16_04.rst
+++ b/doc/guides/rel_notes/release_16_04.rst
@@ -56,6 +56,9 @@ This section should contain new features added in this
release. Sample format:
Added support for sw-firmware sync for resource sharing.
Use the PHY token, shared between sw-fw for PHY access on X550EM_a.
+* **VMDQ DCB mode in i40e.**
+
+ Added support for DCB in VMDQ mode to i40e driver.
Resolved Issues
---
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index ef24122..fc06612 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -8087,6 +8087,8 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
int i, total_tc = 0;
uint16_t qpnum_per_tc, bsf, qp_idx;
struct rte_eth_dev_data *dev_data = I40E_VSI_TO_DEV_DATA(vsi);
+ struct i40e_pf *pf = I40E_VSI_TO_PF(vsi);
+ uint16_t used_queues;
ret = validate_tcmap_parameter(vsi, enabled_tcmap);
if (ret != I40E_SUCCESS)
@@ -8100,7 +8102,18 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
total_tc = 1;
vsi->enabled_tc = enabled_tcmap;
- qpnum_per_tc = dev_data->nb_rx_queues / total_tc;
+ /* different VSI has different queues assigned */
+ if (vsi->type == I40E_VSI_MAIN)
+ used_queues = dev_data->nb_rx_queues -
+ pf->nb_cfg_vmdq_vsi * RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ else if (vsi->type == I40E_VSI_VMDQ2)
+ used_queues = RTE_LIBRTE_I40E_QUEUE_NUM_PER_VM;
+ else {
+ PMD_INIT_LOG(ERR, "unsupported VSI type.");
+ return I40E_ERR_NO_AVAILABLE_VSI;
+ }
+
+ qpnum_per_tc = used_queues / total_tc;
/* Number of queues per enabled TC */
if (qpnum_per_tc == 0) {
PMD_INIT_LOG(ERR, " number of queues is less that tcs.");
@@ -8145,6 +8158,93 @@ i40e_vsi_update_queue_mapping(struct i40e_vsi *vsi,
}
/*
+ * i40e_config_switch_comp_tc - Configure VEB tc setting for given TC map
+ * @veb: VEB to be configured
+ * @tc_map: enabled TC bitmap
+ *
+ * Returns 0 on success, negative value on failure
+ */
+static enum i40e_status_code
+i40e_config_switch_comp_tc(struct i40e_veb *veb, uint8_t tc_map)
+{
+ struct i40e_aqc_configure_switching_comp_bw_config_data veb_bw;
+ struct i40e_aqc_query_switching_comp_bw_config_resp bw_query;
+ struct i40e_aqc_query_switching_comp_ets_config_resp ets_query;
+ struct i40e_hw *hw = I40E_VSI_TO_HW(veb->associate_vsi);
+ enum i40e_status_code ret = I40E_SUCCESS;
+ int i;
+ uint32_t bw_max;
+
+ /* Check if enabled_tc is same as existing or new TCs */
+ if (veb->enabled_tc == tc_map)
+ return ret;
+
+ /* configure tc bandwidth */
+ memset(&veb_bw, 0, sizeof(veb_bw));
+ veb_bw.tc_valid_bits = tc_map;
+ /* Enable ETS TCs with equal BW Share for now across all VSIs */
+ for (i = 0; i < I40E_MAX_TRAFFIC_CLASS; i++) {
+ if (tc_map & BIT_ULL(i))
+ veb_bw.tc_bw_share_credits[i] = 1;
+ }
+ ret = i40e_aq_config_switch_comp_bw_config(hw, veb->seid,
+ &veb_bw, NULL);
+ if (ret) {
+ PMD_INIT_LOG(ERR, "AQ command Config switch_comp BW allocation"
+ " per TC failed = %d",
+ hw->aq.asq_last_status);
+ return ret;
+ }
+
+ memset(&ets_query, 0, sizeof(ets_query));
+ ret = i40e_aq_query_switch_comp_ets_config(hw, veb->seid,
+ &ets_query, NULL);
+ if (ret != I40E_SUCCESS) {
+ PMD_DRV_LOG(ERR, "Failed to get switch_comp ETS"
+" configuration %u", hw->aq.asq_last_status);
+ return ret;
+ }
+ memset(&bw_query, 0, size
[dpdk-dev] [PATCH v2 2/3] ixgbe: disallow unsupported RX mode
The multi queue mode ETH_MQ_RX_VMDQ_DCB_RSS is not supported in
ixgbe driver. This patch added the checking.
Signed-off-by: Jingjing Wu
---
drivers/net/ixgbe/ixgbe_ethdev.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index a1596b3..ce32cbc 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -1855,6 +1855,11 @@ ixgbe_check_mq_mode(struct rte_eth_dev *dev)
return -EINVAL;
}
} else {
+ if (dev_conf->rxmode.mq_mode == ETH_MQ_RX_VMDQ_DCB_RSS) {
+ PMD_INIT_LOG(ERR, "VMDQ+DCB+RSS mq_mode is"
+ " not supported.");
+ return -EINVAL;
+ }
/* check configuration for vmdb+dcb mode */
if (dev_conf->rxmode.mq_mode == ETH_MQ_RX_VMDQ_DCB) {
const struct rte_eth_vmdq_dcb_conf *conf;
--
2.4.0
[dpdk-dev] [PATCH v2 2/5] drivers/net/pcap: add public api to create pcap device
Hello!
> diff --git a/drivers/net/pcap/rte_pmd_pcap_version.map
> b/drivers/net/pcap/rte_pmd_pcap_version.map
> index ef35398..104dc4d 100644
> --- a/drivers/net/pcap/rte_pmd_pcap_version.map
> +++ b/drivers/net/pcap/rte_pmd_pcap_version.map
> @@ -2,3 +2,11 @@ DPDK_2.0 {
>
> local: *;
> };
> +
> +DPDK_2.3 {
> + global:
> +
> + rte_eth_from_pcapsndumpers;
> +
> +} DPDK_2.0;
> +
This one produces style warning upon git am:
--- cut ---
Applying: drivers/net/pcap: add public api to create pcap
/home/p.fedin/dpdk/.git/rebase-apply/patch:333: new blank line at EOF.
+
--- cut ---
I guess the last empty line is not needed
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
[dpdk-dev] thoughts on DPDK after a few days of reading sources
Hi Alejandro, thanks for the heads up - to make sure I got your correctly I assume you refer to: [1]: dpdk: http://dpdk.org/browse/dpdk/commit/?id=e61512e4066740847ced4a85ee9c3334b511468f [2]: kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=033291eccbdb [3]: kernel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ae5515d66362b9d96cdcfce504567f0b8b7bd83e [4]: kenrel: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=03a76b60f8ba27974e2d252bc555d2c103420e15 It seems we will be shipping DPDK 2.2 and Kernel 4.4 with the next release (no commitment being made). [1] is not in DPDK 2.2, so it won't be supported right away. If it can be used without [1] I wouldn't have realized that yet. But also in the kernel it is not only disabled by default - in fact the code itself got removed [3] and only later back into 4.5 [4]. I guess, to really activate, exploit, test and eventually support it - it would be up to an explicit request to do so which can then be evaluated against the risks. IMHO I think we have to wait and see how it will be workin in DPDK >=16.x and Kernel >=4.5 this kind of referring to [3] "... so rather than support an unproven kernel interface revert it and revisit ...". Thanks for the heads up Alejandro, I didn't really think much about it before - I'll revisit it every now and then to see how development around it goes on. Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd On Thu, Feb 11, 2016 at 12:58 PM, Alejandro Lucero < alejandro.lucero at netronome.com> wrote: > Hi Seth, > > I do not know if you and Ubuntu know about the kernel VFIO no-iommu mode > which DPDK will use in the future (then getting rid of UIO drives). > > This implies distributions enabling that kernel VFIO mode which is not > enable by default as it is a security issue. > > It would be good to know which is the Ubuntu position regarding this issue > and if there are any date or plan for supporting this. > > Thanks > > On Thu, Feb 11, 2016 at 7:58 AM, Thomas Monjalon < > thomas.monjalon at 6wind.com> > wrote: > > > Hi, > > > > 2016-02-10 19:05, Seth Arnold: > > > I've taken some notes while reading the sources; I'm sharing them in > the > > > hopes that it's useful: on the one hand my fresh eyes may spot things > > that > > > you've overlooked, on the other hand your familiarity with the code > means > > > that you're better suited to judge what I've found. > > > > Thanks for taking time and sharing, it's very valuable. > > > > > - shellcheck reports extensive cases of forgotten quotes to prevent > word > > > splitting or globbing, potentially unused variables, error-prone > printf > > > formatting. The scripts that are going to be used at runtime should > be > > > fixed: > > > - ./debian/dpdk-init > > > - ./debian/dpdk.init > > > > These files are not in the tree. Should they? > > > > > - ./drivers/net/cxgbe/cxgbe_ethdev.c eth_cxgbe_dev_init() memory leak > in > > > out_free_adapter: that doesn't free adapter > > > - ./drivers/net/virtio/virtio_ethdev.c virtio_set_multiple_queues() > calls > > > virtio_send_command(), which performs: > > > memcpy(vq->virtio_net_hdr_mz->addr, ctrl, sizeof(struct > > virtio_pmd_ctrl)); > > > This copies a potentially huge amount of uninitialized data into > ->addr > > > because the struct virtio_pmd_ctrl ctrl was not zeroed before being > > > passed. How much of this data leaves the system? Does this require a > > > CVE? > > > > We are not used to open a CVE. > > > > [...] > > > It's nearly impossible to solve issues without error reporting. Good > > > error reporting saves admins time and money. > > > > Until now, the errors were reported on the list and most often fixed > > quickly. > > While I agree we need a more formal process (a bug tracker), I think we > > must > > be noticed of new bugs on the mailing list. > > Since nobody was against the bugzilla proposal, a deployment will be > > planned. > > http://dpdk.org/ml/archives/dev/2015-August/023012.html > > >
[dpdk-dev] [PATCH v2] doc: introduce networking driver matrix
Hi Thomas, On Tuesday, February 02/16/16, 2016 at 05:42:30 -0800, Thomas Monjalon wrote: > 2016-02-16 17:05, Rahul Lakkireddy: > > Hi Thomas, > > > > Got a couple of questions on how to mark some of the features for CXGBE > > below. > > > > On Wednesday, January 01/27/16, 2016 at 21:07:09 +0100, Thomas Monjalon > > wrote: > [...] > > > + VLAN filter > > > + ethertype filter > > > + n-tuple filter > > > + SYN filter > > > + tunnel filter > > > + flexible filter > > > + hash filter > > > + flow director > > > > It is possible to set some of the above filters via our cxgbe flow > > director. Do we mark these filter features as supported? > > How do you configure these filters? rte_eth_dev_filter_ctrl()? > Which type in rte_filter_type? > Yes, we configure it with rte_eth_dev_filter_ctrl() and with RTE_ETH_FILTER_FDIR filter type. With Chelsio hardware it's possible to match several different filters in the same rule. For e.g., it's possible to set a vlan, ethertype, and n-tuple filters all on the same rule. The generic architecture [1] for flow director can accept these several filters in the same rule and hence the cxgbe flow director can handle these different filters with this generic approach. [1] http://dpdk.org/ml/archives/dev/2016-February/032605.html Thanks, Rahul
[dpdk-dev] [PATCH v2 4/5] lib/librte_eal: add tcpdump support in primary process
Hello!
> +static int
> +compare_filter(struct rte_mbuf *pkt)
> +{
> + struct ipv4_hdr *pkt_hdr = rte_pktmbuf_mtod_offset(pkt, struct ipv4_hdr
> *,
> + sizeof(struct ether_hdr));
> + if (pkt_hdr->src_addr != src_ip_filter)
> + return -1;
> +
> + return 0;
> +}
Some critics to this...
What if i want to capture packets coming from more than one host?
What if i want to capture all packets?
What if it's not IPv4 at all?
May be this function should always return 0 if src_ip_filter == 0? This would
at least be a quick way to disable filtering.
Kind regards,
Pavel Fedin
Senior Engineer
Samsung Electronics Research center Russia
[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging
On 01/23/2016 04:22 AM, Wiles, Keith wrote: > On 1/22/16, 1:45 AM, "Panu Matilainen" wrote: >> We wouldn't be discussing this if it was not an issue. It is offensive >> enough to turn away both users and contributors, and merely speeding up >> a bit is not going to make it a whole lot better. >> >> As I (and now others as well) already suggested changing it to a one >> line printout is what would make worlds of difference while still >> complying with the license AFAICT. The license text requires printing >> out the copyright notice, it does not say anything about rendering it in >> full-screen ascii-art, or printing out the entire license. > > Thank you Panu for your input, I will think about. Looking at pktgen 2.9.12 and seeing all the ugly startup goo is now gone, its my turn to THANK YOU! - Panu -
[dpdk-dev] [PATCH v3] PCI: ABI change request for adding new field in rte_pci_id structure
On Wed, Feb 17, 2016 at 09:54:33AM +0800, Ziye Yang wrote: > From: Ziye > > The purpose of this patch is used to add a new field > "class" in rte_pci_id structure. The new class field includes > class_id, subcalss_id, programming interface of a pci device. > With this field, we can identify pci device by its class info, > which can be more flexible instead of probing the device by > vendor_id OR device_id OR subvendor_id OR subdevice_id. > For example, we can probe all nvme devices by class field, which > can be quite convenient. > > Signed-off-by: Ziye Yang Acked-by: Bruce Richardson
[dpdk-dev] [PATCH] pcap: fix captured frame length
Hi,
I'm just adding the Acked-by line to the patch. Apologise I missed that one
earlier.
Nico.
On 28/01/16 11:09, Dror Birkman wrote:
> The actual captured length is header.caplen, whereas header.len is
> the original length on the wire.
>
> Signed-off-by: Dror Birkman
> Acked-by: Nicolas Pernas Maradei
> ---
>
>
> Without this fix, if the captured length is smaller than the original
> length on the wire, mbuf will contain incorrect data.
>
>
> drivers/net/pcap/rte_eth_pcap.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/pcap/rte_eth_pcap.c b/drivers/net/pcap/rte_eth_pcap.c
> index f9230eb..1d121f8 100644
> --- a/drivers/net/pcap/rte_eth_pcap.c
> +++ b/drivers/net/pcap/rte_eth_pcap.c
> @@ -220,25 +220,25 @@ eth_pcap_rx(void *queue,
> buf_size =
> (uint16_t)(rte_pktmbuf_data_room_size(pcap_q->mb_pool) -
> RTE_PKTMBUF_HEADROOM);
>
> - if (header.len <= buf_size) {
> + if (header.caplen <= buf_size) {
> /* pcap packet will fit in the mbuf, go ahead and copy
> */
> rte_memcpy(rte_pktmbuf_mtod(mbuf, void *), packet,
> - header.len);
> - mbuf->data_len = (uint16_t)header.len;
> + header.caplen);
> + mbuf->data_len = (uint16_t)header.caplen;
> } else {
> /* Try read jumbo frame into multi mbufs. */
> if (unlikely(eth_pcap_rx_jumbo(pcap_q->mb_pool,
> mbuf,
> packet,
> -header.len) == -1))
> +header.caplen) == -1))
> break;
> }
>
> - mbuf->pkt_len = (uint16_t)header.len;
> + mbuf->pkt_len = (uint16_t)header.caplen;
> mbuf->port = pcap_q->in_port;
> bufs[num_rx] = mbuf;
> num_rx++;
> - rx_bytes += header.len;
> + rx_bytes += header.caplen;
> }
> pcap_q->rx_pkts += num_rx;
> pcap_q->rx_bytes += rx_bytes;
[dpdk-dev] [PATCH] config: add default linux configuration
Hi Thomas, > -Original Message- > From: Yigit, Ferruh > Sent: Tuesday, February 16, 2016 12:09 PM > To: Thomas Monjalon > Cc: dev at dpdk.org; Iremonger, Bernard > Subject: Re: [dpdk-dev] [PATCH] config: add default linux configuration > > On Tue, Feb 16, 2016 at 12:23:12PM +0100, Thomas Monjalon wrote: > > 2016-02-16 11:16, Ferruh Yigit: > > > On Thu, Jan 28, 2016 at 02:31:45PM +, Bernard Iremonger wrote: > > > > add config/defconfig_x86_64-default-linuxapp-gcc file. > > > > > > > > Signed-off-by: Bernard Iremonger > > > > > > Apart from configuration related discussion, this patch was helpful > > > for me to notice "default" machine type, and difference between > > > "native", so I believe it is good to have this as sample config. > > > > The justification is strange. We are not going to have a config file > > for every combinations. > > > Simply I found useful for me and thought others can be useful too, if you > think not useful, that is OK, and yes probably we shouldn't have a sample for > every combination and this patch is not suggesting that. > > > Defaulting defconfig files to the native machine natural to me. > > > No issue on having native machine type, just another defconfig with another > machine type. The default config is useful when working with VM's, that is why I would like to add it. I don't think it is necessary to add default configs for all the compilers, one sample should be enough. > > > > Also not scope of this patch but I agree on Bruce's comment on > > > renaming "default" machine type to "generic", I can send a patch for this > if there is a demand. > > > > default is an Intel core 2. Why generic is a better name? > > When you have "x86_64-default-linuxapp-icc", this feels like this is default > configuration for given architecture among others, which will give best > performance (what native suggests) If I would know nothing about DPDK and > see available configs first time, I would pick this one, because this is > default > one J. > > "generic" stress more that this config supports generic features of different > machine types. > > But this is how I feel, as I said I would prefer "generic", but I can survive > with > existing one. > > Thanks, > Ferruh Regards, Bernard.
[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
Hi, > From: marc.sune at gmail.com [mailto:marc.sune at gmail.com] On Behalf Of > Marc > Sent: Tuesday, February 16, 2016 11:19 PM > To: Matthew Hall > Cc: De Lara Guarch, Pablo; Mcnamara, John; dev at dpdk.org > Subject: Re: [dpdk-dev] x86_64-native-linuxapp-clang compilation broken? > > > > On 16 February 2016 at 19:47, Matthew Hall > wrote: > On Tue, Feb 16, 2016 at 12:57:24PM +, De Lara Guarch, Pablo wrote: > > We suspect this might be an architecture dependent issue. > > Could you tell us which CPU you are using? > > > > Thanks, > > Pablo > > When it happens to me I am using a Skylake Core i7-6700K. > > Broadwell qemu emulated.
[dpdk-dev] [PATCH v2 0/4] Add PCAP support to source and sink port
This patchset adds feature to source and sink type port in librte_port library, and to examples/ip_pipline. Originally, source/sink ports act as input and output of NULL packets generator. This patchset enables them read from and write to specific PCAP file, to generate and dump packets. v2: *fixed source/sink open function returns *removed duplicated code *added clearer error message display on different error messages Acked-by: Cristian Dumitrescu Fan Zhang (4): lib/librte_port: add PCAP file support to source port example/ip_pipeline: add PCAP file support lib/librte_port: add packet dumping to PCAP file support in sink port examples/ip_pipeline: add packets dumping to PCAP file support config/common_bsdapp | 1 + config/common_linuxapp | 1 + examples/ip_pipeline/app.h | 4 + examples/ip_pipeline/config_parse.c| 261 +++- examples/ip_pipeline/init.c| 22 ++ examples/ip_pipeline/pipeline_be.h | 2 + lib/librte_port/Makefile | 4 + lib/librte_port/rte_port_source_sink.c | 430 - lib/librte_port/rte_port_source_sink.h | 18 +- mk/rte.app.mk | 1 + 10 files changed, 739 insertions(+), 5 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH v2 1/4] lib/librte_port: add PCAP file support to source port
Originally, source ports in librte_port is an input port used as packet
generator. Similar to Linux kernel /dev/zero character device, it
generates null packets. This patch adds optional PCAP file support to
source port: instead of sending NULL packets, the source port generates
packets copied from a PCAP file. To increase the performance, the packets
in the file are loaded to memory initially, and copied to mbufs in circular
manner. Users can enable or disable this feature by setting
CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
config/common_bsdapp | 1 +
config/common_linuxapp | 1 +
lib/librte_port/Makefile | 4 +
lib/librte_port/rte_port_source_sink.c | 226 -
lib/librte_port/rte_port_source_sink.h | 7 +
mk/rte.app.mk | 1 +
6 files changed, 239 insertions(+), 1 deletion(-)
diff --git a/config/common_bsdapp b/config/common_bsdapp
index ed7c31c..1eb36ae 100644
--- a/config/common_bsdapp
+++ b/config/common_bsdapp
@@ -459,6 +459,7 @@ CONFIG_RTE_LIBRTE_REORDER=y
#
CONFIG_RTE_LIBRTE_PORT=y
CONFIG_RTE_PORT_STATS_COLLECT=n
+CONFIG_RTE_PORT_PCAP=n
#
# Compile librte_table
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 74bc515..776fcd3 100644
--- a/config/common_linuxapp
+++ b/config/common_linuxapp
@@ -476,6 +476,7 @@ CONFIG_RTE_LIBRTE_REORDER=y
#
CONFIG_RTE_LIBRTE_PORT=y
CONFIG_RTE_PORT_STATS_COLLECT=n
+CONFIG_RTE_PORT_PCAP=n
#
# Compile librte_table
diff --git a/lib/librte_port/Makefile b/lib/librte_port/Makefile
index 410053e..e3e4318 100644
--- a/lib/librte_port/Makefile
+++ b/lib/librte_port/Makefile
@@ -36,6 +36,10 @@ include $(RTE_SDK)/mk/rte.vars.mk
#
LIB = librte_port.a
+ifeq ($(CONFIG_RTE_PORT_PCAP),y)
+LDLIBS += -lpcap
+endif
+
CFLAGS += -O3
CFLAGS += $(WERROR_FLAGS)
diff --git a/lib/librte_port/rte_port_source_sink.c
b/lib/librte_port/rte_port_source_sink.c
index a06477e..086c51a 100644
--- a/lib/librte_port/rte_port_source_sink.c
+++ b/lib/librte_port/rte_port_source_sink.c
@@ -36,6 +36,11 @@
#include
#include
#include
+#include
+
+#ifdef RTE_PORT_PCAP
+#include
+#endif
#include "rte_port_source_sink.h"
@@ -60,14 +65,175 @@ struct rte_port_source {
struct rte_port_in_stats stats;
struct rte_mempool *mempool;
+
+ /* PCAP buffers and indexes */
+ uint8_t **pkts;
+ uint8_t *pkt_buff;
+ uint32_t *pkt_len;
+ uint32_t n_pkts;
+ uint32_t pkt_index;
};
+#ifdef RTE_PORT_PCAP
+
+/**
+ * Load PCAP file, allocate and copy packets in the file to memory
+ *
+ * @param p
+ * Parameters for source port
+ * @param port
+ * Handle to source port
+ * @param socket_id
+ * Socket id where the memory is created
+ * @return
+ * 0 on SUCCESS
+ * error code otherwise
+ */
+static int
+pcap_source_load(struct rte_port_source_params *p,
+ struct rte_port_source *port,
+ int socket_id)
+{
+ uint32_t status = 0;
+ uint32_t n_pkts = 0;
+ uint32_t i;
+ uint32_t *pkt_len_aligns = NULL;
+ size_t total_buff_len = 0;
+ pcap_t *pcap_handle;
+ char pcap_errbuf[PCAP_ERRBUF_SIZE];
+ uint32_t max_len;
+ struct pcap_pkthdr pcap_hdr;
+ const uint8_t *pkt;
+ uint8_t *buff = NULL;
+ uint32_t pktmbuf_maxlen = (uint32_t)
+ (rte_pktmbuf_data_room_size(port->mempool) -
+ RTE_PKTMBUF_HEADROOM);
+
+ if (p->file_name == NULL)
+ return 0;
+
+ if (p->n_bytes_per_pkt == 0)
+ max_len = pktmbuf_maxlen;
+ else
+ max_len = RTE_MIN(p->n_bytes_per_pkt, pktmbuf_maxlen);
+
+ /* first time open, get packet number */
+ pcap_handle = pcap_open_offline(p->file_name, pcap_errbuf);
+ if (pcap_handle == NULL) {
+ status = -ENOENT;
+ goto error_exit;
+ }
+
+ while ((pkt = pcap_next(pcap_handle, &pcap_hdr)) != NULL)
+ n_pkts++;
+
+ pcap_close(pcap_handle);
+
+ port->pkt_len = rte_zmalloc_socket("PCAP",
+ (sizeof(*port->pkt_len) * n_pkts), 0, socket_id);
+ if (port->pkt_len == NULL) {
+ status = -ENOMEM;
+ goto error_exit;
+ }
+
+ pkt_len_aligns = rte_malloc("PCAP",
+ (sizeof(*pkt_len_aligns) * n_pkts), 0);
+ if (pkt_len_aligns == NULL) {
+ status = -ENOMEM;
+ goto error_exit;
+ }
+
+ port->pkts = rte_zmalloc_socket("PCAP",
+ (sizeof(*port->pkts) * n_pkts), 0, socket_id);
+ if (port->pkts == NULL) {
+ status = -ENOMEM;
+ goto error_exit;
+ }
+
+ /* open 2nd time, get pkt_len */
+ pcap_handle = pcap_open_offline(p->file_name, pcap_errbuf);
+ if (pcap_handle == NULL) {
+ status = -ENOENT;
+
[dpdk-dev] [PATCH v2 2/4] example/ip_pipeline: add PCAP file support
This patch add PCAP file support to ip_pipeline. Input port type SOURCE
now supports loading specific PCAP file and sends the packets in it to
pipeline instance. The packets are then released by SINK output port. This
feature can be applied by specifying parameters in configuration file as
shown below;
[PIPELINE1]
type = PASS-THROUGH
core = 1
pktq_in = SOURCE0 SOURCE1
pktq_out = SINK0 SINK1
pcap_file_rd = /path/to/eth1.PCAP /path/to/eth2.PCAP
pcap_bytes_rd_per_pkt = 0 64
The configuration section "pcap_file_rd" contains full path and name of
the PCAP file to be loaded. If multiple SOURCEs exists, each shall have
its own PCAP file path listed in this section, separated by spaces.
Multiple SOURCE ports may share same PCAP file to be copied.
The configuration section "pcap_bytes_rd_per_pkt" contains integer value
and indicates the maximum number of bytes to be copied from each packet
in the PCAP file. If this value is "0", all packets in the file will be
copied fully; if the packet size is smaller than the assigned value, the
entire packet is copied. Same as "pcap_file_rd", every SOURCE shall have
its own maximum copy byte number.
To enable PCAP support to IP pipeline, the compiler option
CONFIG_RTE_PORT_PCAP must be set to 'y'. It is possible to disable PCAP
support by removing "pcap_file_rd" and "pcap_bytes_rd_per_pkt" lines
from the configuration file.
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/app.h | 2 +
examples/ip_pipeline/config_parse.c | 102 +++-
examples/ip_pipeline/init.c | 11
3 files changed, 113 insertions(+), 2 deletions(-)
diff --git a/examples/ip_pipeline/app.h b/examples/ip_pipeline/app.h
index 6510d6d..9dbe668 100644
--- a/examples/ip_pipeline/app.h
+++ b/examples/ip_pipeline/app.h
@@ -148,6 +148,8 @@ struct app_pktq_source_params {
uint32_t parsed;
uint32_t mempool_id; /* Position in the app->mempool_params array */
uint32_t burst;
+ char *file_name; /* Full path of PCAP file to be copied to mbufs */
+ uint32_t n_bytes_per_pkt;
};
struct app_pktq_sink_params {
diff --git a/examples/ip_pipeline/config_parse.c
b/examples/ip_pipeline/config_parse.c
index 1bedbe4..f0bed81 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -178,6 +178,8 @@ struct app_pktq_source_params default_source_params = {
.parsed = 0,
.mempool_id = 0,
.burst = 32,
+ .file_name = NULL,
+ .n_bytes_per_pkt = 0,
};
struct app_pktq_sink_params default_sink_params = {
@@ -924,6 +926,83 @@ parse_eal(struct app_params *app,
}
static int
+parse_pipeline_pcap_source(struct app_params *app,
+ struct app_pipeline_params *p,
+ const char *file_name, const char *cp_size)
+{
+ const char *next = NULL;
+ char *end;
+ uint32_t i;
+ int parse_file = 0;
+
+ if (file_name && !cp_size) {
+ next = file_name;
+ parse_file = 1; /* parse file path */
+ } else if (cp_size && !file_name) {
+ next = cp_size;
+ parse_file = 0; /* parse copy size */
+ } else
+ return -EINVAL;
+
+ char name[APP_PARAM_NAME_SIZE];
+ size_t name_len;
+
+ if (p->n_pktq_in == 0)
+ return -EINVAL;
+
+ for (i = 0; i < p->n_pktq_in; i++) {
+ if (p->pktq_in[i].type != APP_PKTQ_IN_SOURCE)
+ return -EINVAL;
+ }
+
+ i = 0;
+ while (*next != '\0') {
+ uint32_t id;
+
+ if (i >= p->n_pktq_in)
+ return -EINVAL;
+
+ id = p->pktq_in[i].id;
+
+ end = strchr(next, ' ');
+ if (!end)
+ name_len = strlen(next);
+ else
+ name_len = end - next;
+
+ if (name_len == 0 || name_len == sizeof(name))
+ return -EINVAL;
+
+ strncpy(name, next, name_len);
+ name[name_len] = '\0';
+ next += name_len;
+ if (*next != '\0')
+ next++;
+
+ if (parse_file) {
+ app->source_params[id].file_name = strdup(name);
+ if (app->source_params[id].file_name == NULL)
+ return -ENOMEM;
+ } else {
+ if (parser_read_uint32(
+ &app->source_params[id].n_bytes_per_pkt,
+ name) != 0) {
+ if (app->source_params[id].file_name != NULL)
+ free(app->source_params[id].file_name);
+ return -EINVAL;
+ }
+ }
+
+ i++;
+
+ if (i == p->n_pktq_in)
+ return 0;
+
[dpdk-dev] [PATCH v2 3/4] lib/librte_port: add packet dumping to PCAP file support in sink port
Originally, sink ports in librte_port releases received mbufs back to
mempool. This patch adds optional packet dumping to PCAP feature in sink
port: the packets will be dumped to user defined PCAP file for storage or
debugging. The user may also choose the sink port's activity: either it
continuously dump the packets to the file, or stops at certain dumping
This feature shares same CONFIG_RTE_PORT_PCAP compiler option as source
port PCAP file support feature. Users can enable or disable this feature
by setting CONFIG_RTE_PORT_PCAP compiler option "y" or "n".
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
lib/librte_port/rte_port_source_sink.c | 248 -
lib/librte_port/rte_port_source_sink.h | 11 +-
2 files changed, 256 insertions(+), 3 deletions(-)
diff --git a/lib/librte_port/rte_port_source_sink.c
b/lib/librte_port/rte_port_source_sink.c
index 086c51a..b54dce0 100644
--- a/lib/librte_port/rte_port_source_sink.c
+++ b/lib/librte_port/rte_port_source_sink.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#ifdef RTE_PORT_PCAP
#include
@@ -379,12 +380,183 @@ rte_port_source_stats_read(void *port,
struct rte_port_sink {
struct rte_port_out_stats stats;
+
+ /* PCAP dumper handle and pkts number */
+ void *dumper;
+ uint32_t max_pkts;
+ uint32_t pkt_index;
+ uint32_t dump_finish;
};
+#ifdef RTE_PORT_PCAP
+
+/**
+ * Open PCAP file for dumping packets to the file later
+ *
+ * @param port
+ * Handle to sink port
+ * @param p
+ * Sink port parameter
+ * @return
+ * 0 on SUCCESS
+ * error code otherwise
+ */
+static int
+pcap_sink_open(struct rte_port_sink *port,
+ __rte_unused struct rte_port_sink_params *p)
+{
+ pcap_t *tx_pcap;
+ pcap_dumper_t *pcap_dumper;
+
+ if (p->file_name == NULL) {
+ port->dumper = NULL;
+ port->max_pkts = 0;
+ port->pkt_index = 0;
+ port->dump_finish = 0;
+ return 0;
+ }
+
+ /** Open a dead pcap handler for opening dumper file */
+ tx_pcap = pcap_open_dead(DLT_EN10MB, 65535);
+ if (tx_pcap == NULL)
+ return -ENOENT;
+
+ /* The dumper is created using the previous pcap_t reference */
+ pcap_dumper = pcap_dump_open(tx_pcap, p->file_name);
+ if (pcap_dumper == NULL)
+ return -ENOENT;
+
+ port->dumper = pcap_dumper;
+ port->max_pkts = p->max_n_pkts;
+ port->pkt_index = 0;
+ port->dump_finish = 0;
+
+ return 0;
+}
+
+uint8_t jumbo_pkt_buf[ETHER_MAX_JUMBO_FRAME_LEN];
+
+/**
+ * Dump a packet to PCAP dumper
+ *
+ * @param p
+ * Handle to sink port
+ * @param mbuf
+ * Handle to mbuf structure holding the packet
+ */
+static void
+pcap_sink_dump_pkt(struct rte_port_sink *port, struct rte_mbuf *mbuf)
+{
+ uint8_t *pcap_dumper = (uint8_t *)(port->dumper);
+ struct pcap_pkthdr pcap_hdr;
+ uint8_t *pkt;
+
+ /* Maximum num packets already reached */
+ if (port->dump_finish)
+ return;
+
+ pkt = rte_pktmbuf_mtod(mbuf, uint8_t *);
+
+ pcap_hdr.len = mbuf->pkt_len;
+ pcap_hdr.caplen = pcap_hdr.len;
+ gettimeofday(&(pcap_hdr.ts), NULL);
+
+ if (mbuf->nb_segs > 1) {
+ struct rte_mbuf *jumbo_mbuf;
+ uint32_t pkt_index = 0;
+
+ /* if packet size longer than ETHER_MAX_JUMBO_FRAME_LEN,
+* ignore it.
+*/
+ if (mbuf->pkt_len > ETHER_MAX_JUMBO_FRAME_LEN)
+ return;
+
+ for (jumbo_mbuf = mbuf; jumbo_mbuf != NULL;
+ jumbo_mbuf = jumbo_mbuf->next) {
+ rte_memcpy(&jumbo_pkt_buf[pkt_index],
+ rte_pktmbuf_mtod(jumbo_mbuf, uint8_t *),
+ jumbo_mbuf->data_len);
+ pkt_index += jumbo_mbuf->data_len;
+ }
+
+ jumbo_pkt_buf[pkt_index] = '\0';
+
+ pkt = jumbo_pkt_buf;
+ }
+
+ pcap_dump(pcap_dumper, &pcap_hdr, pkt);
+
+ port->pkt_index++;
+
+ if ((port->max_pkts != 0) && (port->pkt_index >= port->max_pkts)) {
+ port->dump_finish = 1;
+ RTE_LOG(INFO, PORT, "Dumped %u packets to file\n",
+ port->pkt_index);
+ }
+
+}
+
+/**
+ * Flush pcap dumper
+ *
+ * @param dumper
+ * Handle to pcap dumper
+ */
+
+static void
+pcap_sink_flush_pkt(void *dumper)
+{
+ pcap_dumper_t *pcap_dumper = (pcap_dumper_t *)dumper;
+
+ pcap_dump_flush(pcap_dumper);
+}
+
+/**
+ * Close a PCAP dumper handle
+ *
+ * @param dumper
+ * Handle to pcap dumper
+ */
+static void
+pcap_sink_close(void *dumper)
+{
+ pcap_dumper_t *pcap_dumper = (pcap_dumper_t *)dumper;
+
+ pcap_dump_close(pcap_dumper);
+}
+
+#else
+
+static int
+pcap_sink_open(struct rte_port_sink *port,
[dpdk-dev] [PATCH v2 4/4] examples/ip_pipeline: add packets dumping to PCAP file support
This patch add packet dumping feature to ip_pipeline. Output port type
SINK now supports dumping packets to PCAP file before releasing mbuf back
to mempool. This feature can be applied by specifying parameters in
configuration file as shown below:
[PIPELINE1]
type = PASS-THROUGH
core = 1
pktq_in = SOURCE0 SOURCE1
pktq_out = SINK0 SINK1
pcap_file_wr = /path/to/eth1.pcap /path/to/eth2.pcap
pcap_n_pkt_wr = 80 0
The configuration section "pcap_file_wr" contains full path and name of
the PCAP file which the packets will be dumped to. If multiple SINKs
exists, each shall have its own PCAP file path listed in this section,
separated by spaces. Multiple SINK ports shall NOT share same PCAP file to
be dumped.
The configuration section "pcap_n_pkt_wr" contains integer value(s)
and indicates the maximum number of packets to be dumped to the PCAP file.
If this value is "0", the "infinite" dumping mode will be used. If this
value is N (N > 0), the dumping will be finished when the number of
packets dumped to the file reaches N.
To enable PCAP dumping support to IP pipeline, the compiler option
CONFIG_RTE_PORT_PCAP must be set to 'y'. It is possible to disable this
feature by removing "pcap_file_wr" and "pcap_n_pkt_wr" lines from the
configuration file.
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/app.h | 2 +
examples/ip_pipeline/config_parse.c | 159
examples/ip_pipeline/init.c | 11 +++
examples/ip_pipeline/pipeline_be.h | 2 +
4 files changed, 174 insertions(+)
diff --git a/examples/ip_pipeline/app.h b/examples/ip_pipeline/app.h
index 9dbe668..144fab8 100644
--- a/examples/ip_pipeline/app.h
+++ b/examples/ip_pipeline/app.h
@@ -155,6 +155,8 @@ struct app_pktq_source_params {
struct app_pktq_sink_params {
char *name;
uint8_t parsed;
+ char *file_name; /* Full path of PCAP file to be copied to mbufs */
+ uint32_t n_pkts_to_dump;
};
struct app_msgq_params {
diff --git a/examples/ip_pipeline/config_parse.c
b/examples/ip_pipeline/config_parse.c
index f0bed81..9f5b974 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -184,6 +184,8 @@ struct app_pktq_source_params default_source_params = {
struct app_pktq_sink_params default_sink_params = {
.parsed = 0,
+ .file_name = NULL,
+ .n_pkts_to_dump = 0,
};
struct app_msgq_params default_msgq_params = {
@@ -1003,6 +1005,83 @@ parse_pipeline_pcap_source(struct app_params *app,
}
static int
+parse_pipeline_pcap_sink(struct app_params *app,
+ struct app_pipeline_params *p,
+ const char *file_name, const char *n_pkts_to_dump)
+{
+ const char *next = NULL;
+ char *end;
+ uint32_t i;
+ int parse_file = 0;
+
+ if (file_name && !n_pkts_to_dump) {
+ next = file_name;
+ parse_file = 1; /* parse file path */
+ } else if (n_pkts_to_dump && !file_name) {
+ next = n_pkts_to_dump;
+ parse_file = 0; /* parse copy size */
+ } else
+ return -EINVAL;
+
+ char name[APP_PARAM_NAME_SIZE];
+ size_t name_len;
+
+ if (p->n_pktq_out == 0)
+ return -EINVAL;
+
+ for (i = 0; i < p->n_pktq_out; i++) {
+ if (p->pktq_out[i].type != APP_PKTQ_OUT_SINK)
+ return -EINVAL;
+ }
+
+ i = 0;
+ while (*next != '\0') {
+ uint32_t id;
+
+ if (i >= p->n_pktq_out)
+ return -EINVAL;
+
+ id = p->pktq_out[i].id;
+
+ end = strchr(next, ' ');
+ if (!end)
+ name_len = strlen(next);
+ else
+ name_len = end - next;
+
+ if (name_len == 0 || name_len == sizeof(name))
+ return -EINVAL;
+
+ strncpy(name, next, name_len);
+ name[name_len] = '\0';
+ next += name_len;
+ if (*next != '\0')
+ next++;
+
+ if (parse_file) {
+ app->sink_params[id].file_name = strdup(name);
+ if (app->sink_params[id].file_name == NULL)
+ return -ENOMEM;
+ } else {
+ if (parser_read_uint32(
+ &app->sink_params[id].n_pkts_to_dump,
+ name) != 0) {
+ if (app->sink_params[id].file_name != NULL)
+ free(app->sink_params[id].file_name);
+ return -EINVAL;
+ }
+ }
+
+ i++;
+
+ if (i == p->n_pktq_out)
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static int
parse_pipeline_pktq_in(struct app_params *app,
struct app_pipelin
[dpdk-dev] [PATCH v2] examples/ip_pipeline: config parser clean-up
This patch updates the pipelne configuration file parser, cleans up nesting
if/else conditions, and add clearer error message display.
Signed-off-by: Fan Zhang
Acked-by: Cristian Dumitrescu
---
examples/ip_pipeline/config_parse.c| 1008
examples/ip_pipeline/parser.h | 50 +
.../ip_pipeline/pipeline/pipeline_firewall_be.c| 25 +-
.../pipeline/pipeline_flow_actions_be.c| 91 +-
.../pipeline/pipeline_flow_classification_be.c | 142 ++-
.../ip_pipeline/pipeline/pipeline_passthrough_be.c | 140 ++-
.../ip_pipeline/pipeline/pipeline_routing_be.c | 204 ++--
examples/ip_pipeline/pipeline_be.h | 31 +-
8 files changed, 1112 insertions(+), 579 deletions(-)
create mode 100644 examples/ip_pipeline/parser.h
diff --git a/examples/ip_pipeline/config_parse.c
b/examples/ip_pipeline/config_parse.c
index 1bedbe4..5f72af9 100644
--- a/examples/ip_pipeline/config_parse.c
+++ b/examples/ip_pipeline/config_parse.c
@@ -47,6 +47,7 @@
#include
#include "app.h"
+#include "parser.h"
/**
* Default config values
@@ -229,31 +230,19 @@ app_print_usage(char *prgname)
_p; \
})
-#define PARSER_IMPLICIT_PARAM_ADD_CHECK(result, section_name) \
-do { \
- APP_CHECK((result != -EINVAL), \
- "CFG: [%s] name too long", section_name); \
- APP_CHECK(result != -ENOMEM,\
- "CFG: [%s] too much sections", section_name); \
- APP_CHECK(result >= 0, \
- "CFG: [%s] Unknown error while adding '%s'",\
- section_name, section_name);\
-} while (0)
-
#define PARSER_PARAM_ADD_CHECK(result, params_array, section_name) \
do { \
APP_CHECK((result != -EINVAL), \
- "CFG: [%s] name too long", section_name); \
+ "Parse error: no free memory"); \
APP_CHECK((result != -ENOMEM), \
- "CFG: [%s] too much sections", section_name); \
+ "Parse error: too many \"%s\" sections", section_name); \
APP_CHECK(((result >= 0) && (params_array)[result].parsed == 0),\
- "CFG: [%s] duplicate section", section_name); \
+ "Parse error: duplicate \"%s\" section", section_name); \
APP_CHECK((result >= 0),\
- "CFG: [%s] Unknown error while adding '%s'",\
- section_name, section_name);\
+ "Parse error in section \"%s\"", section_name); \
} while (0)
-static int
+int
parser_read_arg_bool(const char *p)
{
p = skip_white_spaces(p);
@@ -318,7 +307,7 @@ APP_CHECK(exp, "Parse error in section \"%s\": unrecognized
entry \"%s\"\n",\
APP_CHECK(exp, "Parse error in section \"%s\": duplicate entry \"%s\"\n",\
section, entry)
-static int
+int
parser_read_uint64(uint64_t *value, const char *p)
{
char *next;
@@ -336,13 +325,13 @@ parser_read_uint64(uint64_t *value, const char *p)
switch (*p) {
case 'T':
val *= 1024ULL;
- /* fall trought */
+ /* fall through */
case 'G':
val *= 1024ULL;
- /* fall trought */
+ /* fall through */
case 'M':
val *= 1024ULL;
- /* fall trought */
+ /* fall through */
case 'k':
case 'K':
val *= 1024ULL;
@@ -358,7 +347,7 @@ parser_read_uint64(uint64_t *value, const char *p)
return 0;
}
-static int
+int
parser_read_uint32(uint32_t *value, const char *p)
{
uint64_t val = 0;
@@ -366,7 +355,8 @@ parser_read_uint32(uint32_t *value, const char *p)
if (ret < 0)
return ret;
- else if (val > UINT32_MAX)
+
+ if (val > UINT32_MAX)
return -ERANGE;
*value = val;
@@ -936,8 +926,25 @@ parse_pipeline_pktq_in(struct app_params *app,
while (*next != '\0') {
enum app_pktq_in_type type;
int id;
+ char *end_space;
+ char *end_tab;
+
+ next = skip_white_spaces(next);
+ if (!next)
+ break;
+
+ end_space = strchr(next, ' ');
+ end_tab = strchr(next, '');
+
+ if (end_space && (!end_tab))
+ end = end_space;
+ else if ((!end_space) && end_tab)
+ end = end_tab;
+
[dpdk-dev] [PATCH 1/4] szedata2: rewrite PMD from virtual PMD_VDEV type to PMD_PDEV type
On Thu, Jan 28, 2016 at 11:23:46PM +0100, Matej Vido wrote: > PMD was of type PMD_VDEV which means that PCI device is not recognised > automatically during EAL initialization, but it has to be created by > EAL option --vdev. > Now, PMD is of type PMD_PDEV which means that PCI device is probed > and recognised during EAL initialization automatically. > Path to szedata2 device file is matched with device and the count > of available RX and TX DMA channels is found out during device > initialization. > Initialization, starting and stopping of queues is changed to better > correspond with Ethernet device API model. Function callbacks > (rx|tx)_queue_(start|stop) are added. Unnecessary items are removed > from ethernet device private data structure. > > Signed-off-by: Matej Vido Series applied to dpdk-net-next/rel_16_04 /Bruce
[dpdk-dev] [PATCH] mlx5: fix header generation in parallel builds
On Fri, Jan 29, 2016 at 11:31:36AM +0100, Adrien Mazarguil wrote:
> Fixes: 771fa900b73a ("mlx5: introduce new driver for Mellanox ConnectX-4
> adapters")
>
> Signed-off-by: Adrien Mazarguil
> ---
Applied to dpdk-next-net/rel_16_04
/Bruce
[dpdk-dev] [PATCH v2] vhost: remove vhost_net_device_ops
On Tue, Feb 16, 2016 at 02:45:04PM -0800, Rich Lane wrote: > The indirection is unnecessary because there is only one implementation > of the vhost common code. Removing it makes the code more readable. > > Signed-off-by: Rich Lane Acked-by: Yuanhan Liu Thanks. --yliu
[dpdk-dev] [PATCH] qat pmd:Fixing build issue on 32-bit systems
Hi Pablo,
Sure - will resubmit a v2 with those modifications.
Thanks,
John.
On 16/02/16 15:52, De Lara Guarch, Pablo wrote:
> Hi John,
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of John Griffin
>> Sent: Tuesday, February 16, 2016 9:45 AM
>> To: dev at dpdk.org
>> Subject: [dpdk-dev] [PATCH] qat pmd:Fixing build issue on 32-bit systems
>>
>> Fixing build issue on 32-bit systems.
>> Fixes: 1703e94ac5ce ("qat: add driver for QuickAssist devices")
>>
>> Signed-off-by: John Griffin
> Acked-by: Pablo de Lara
>
> Could you include the error that you are fixing on this patch?
>
> For example:
>
> drivers/crypto/qat/qat_crypto.c:345:13:
> error: cast to pointer from integer of different size
> [-Werror=int-to-pointer-cast]
>
> Also, as a general rule, patch titles start with lowercase and do not include
> the name "issue" if we use "fix".
> e.g. (qat: fix build on 32-bit systems).
>
> Apart from this, patch looks OK to me, so you can leave the acknowledgment in
> the v2.
>
> Thanks!
> Pablo
>
[dpdk-dev] [PATCH 0/3] ethdev: add helper functions to get eth_dev and dev private data
This is to provide abstraction and reduce global variable access. Global variable rte_eth_devices kept exported to not break ABI. Bonding driver not selected on purpose, just it seems it is using rte_eth_devices heavily. There are a few more usage in drivers but they left as it is because they are in fast path code. Ferruh Yigit (3): ethdev: add helper functions to get eth_dev and dev private data app/test: use ethdev helper functions bonding: use ethdev helper functions app/test/test_link_bonding.c | 35 -- app/test/virtual_pmd.c| 51 + drivers/net/bonding/rte_eth_bond_8023ad.c | 10 ++-- drivers/net/bonding/rte_eth_bond_api.c| 76 +++ drivers/net/bonding/rte_eth_bond_args.c | 13 -- drivers/net/bonding/rte_eth_bond_pmd.c| 47 +++ lib/librte_ether/rte_ethdev.h | 44 ++ 7 files changed, 167 insertions(+), 109 deletions(-) -- 2.5.0
[dpdk-dev] [PATCH 1/3] ethdev: add helper functions to get eth_dev and dev private data
This is to provide abstraction and reduce global variable access.
Global variable rte_eth_devices kept exported to not break ABI.
Signed-off-by: Ferruh Yigit
---
lib/librte_ether/rte_ethdev.h | 44 +++
1 file changed, 44 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 6afb5a9..7209b83 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -3881,6 +3881,50 @@ rte_eth_dma_zone_reserve(const struct rte_eth_dev
*eth_dev, const char *name,
uint16_t queue_id, size_t size,
unsigned align, int socket_id);
+/**
+ * Return rte_eth_dev by port id
+ *
+ * This is to abstract device access and limit global variable access.
+ *
+ * @param port_id
+ * port_id of the device to return.
+ */
+static inline struct rte_eth_dev *
+rte_eth_by_port(uint16_t port_id)
+{
+ return &rte_eth_devices[port_id];
+}
+
+/**
+ * Return rte_eth_dev private data structure by port id
+ *
+ * This is to abstract device private data access and
+ * limit global variable access.
+ *
+ * @param port_id
+ * port_id of the device to return.
+ */
+static inline void *
+rte_eth_private_by_port(uint16_t port_id)
+{
+ return rte_eth_devices[port_id].data->dev_private;
+}
+
+/**
+ * Return rte_eth_dev private data structure by rte_eth_dev
+ *
+ * This is helper function to access device private data, also
+ * provides some abstraction on how private data kept.
+ *
+ * @param dev
+ * rte_eth_dev
+ */
+static inline void *
+rte_eth_private_by_dev(struct rte_eth_dev *dev)
+{
+ return dev->data->dev_private;
+}
+
#ifdef __cplusplus
}
#endif
--
2.5.0
[dpdk-dev] [PATCH 2/3] app/test: use ethdev helper functions
Use rte_eth_by_port(), rte_eth_private_by_port(),
rte_eth_private_by_dev() helper functions.
Signed-off-by: Ferruh Yigit
---
app/test/test_link_bonding.c | 35 +-
app/test/virtual_pmd.c | 51 +++-
2 files changed, 42 insertions(+), 44 deletions(-)
diff --git a/app/test/test_link_bonding.c b/app/test/test_link_bonding.c
index 7cbc289..f2e364b 100644
--- a/app/test/test_link_bonding.c
+++ b/app/test/test_link_bonding.c
@@ -4567,6 +4567,8 @@ test_alb_change_mac_in_reply_sent(void)
struct ether_addr bond_mac, client_mac;
struct ether_addr *slave_mac1, *slave_mac2;
+ struct rte_eth_dev *dev;
+
TEST_ASSERT_SUCCESS(
initialize_bonded_device_with_slaves(BONDING_MODE_ALB,
0, TEST_ALB_SLAVE_COUNT, 1),
@@ -4581,9 +4583,8 @@ test_alb_change_mac_in_reply_sent(void)
MAX_PKT_BURST);
}
- ether_addr_copy(
-
rte_eth_devices[test_params->bonded_port_id].data->mac_addrs,
- &bond_mac);
+ dev = rte_eth_by_port(test_params->bonded_port_id);
+ ether_addr_copy(dev->data->mac_addrs, &bond_mac);
/*
* Generating four packets with different mac and ip addresses and
sending
@@ -4629,10 +4630,10 @@ test_alb_change_mac_in_reply_sent(void)
ARP_OP_REPLY);
rte_eth_tx_burst(test_params->bonded_port_id, 0, &pkt, 1);
- slave_mac1 =
-
rte_eth_devices[test_params->slave_port_ids[0]].data->mac_addrs;
- slave_mac2 =
-
rte_eth_devices[test_params->slave_port_ids[1]].data->mac_addrs;
+ dev = rte_eth_by_port(test_params->slave_port_ids[0]);
+ slave_mac1 = dev->data->mac_addrs;
+ dev = rte_eth_by_port(test_params->slave_port_ids[1]);
+ slave_mac2 = dev->data->mac_addrs;
/*
* Checking if packets are properly distributed on bonding ports.
Packets
@@ -4681,6 +4682,8 @@ test_alb_reply_from_client(void)
struct ether_addr bond_mac, client_mac;
struct ether_addr *slave_mac1, *slave_mac2;
+ struct rte_eth_dev *dev;
+
TEST_ASSERT_SUCCESS(
initialize_bonded_device_with_slaves(BONDING_MODE_ALB,
0, TEST_ALB_SLAVE_COUNT, 1),
@@ -4694,9 +4697,8 @@ test_alb_reply_from_client(void)
MAX_PKT_BURST);
}
- ether_addr_copy(
-
rte_eth_devices[test_params->bonded_port_id].data->mac_addrs,
- &bond_mac);
+ dev = rte_eth_by_port(test_params->bonded_port_id);
+ ether_addr_copy(dev->data->mac_addrs, &bond_mac);
/*
* Generating four packets with different mac and ip addresses and
placing
@@ -4753,8 +4755,10 @@ test_alb_reply_from_client(void)
rte_eth_rx_burst(test_params->bonded_port_id, 0, pkts_sent,
MAX_PKT_BURST);
rte_eth_tx_burst(test_params->bonded_port_id, 0, NULL, 0);
- slave_mac1 =
rte_eth_devices[test_params->slave_port_ids[0]].data->mac_addrs;
- slave_mac2 =
rte_eth_devices[test_params->slave_port_ids[1]].data->mac_addrs;
+ dev = rte_eth_by_port(test_params->slave_port_ids[0]);
+ slave_mac1 = dev->data->mac_addrs;
+ dev = rte_eth_by_port(test_params->slave_port_ids[1]);
+ slave_mac2 = dev->data->mac_addrs;
/*
* Checking if update ARP packets were properly send on slave ports.
@@ -4808,6 +4812,8 @@ test_alb_receive_vlan_reply(void)
struct ether_addr bond_mac, client_mac;
+ struct rte_eth_dev *dev;
+
TEST_ASSERT_SUCCESS(
initialize_bonded_device_with_slaves(BONDING_MODE_ALB,
0, TEST_ALB_SLAVE_COUNT, 1),
@@ -4821,9 +4827,8 @@ test_alb_receive_vlan_reply(void)
MAX_PKT_BURST);
}
- ether_addr_copy(
-
rte_eth_devices[test_params->bonded_port_id].data->mac_addrs,
- &bond_mac);
+ dev = rte_eth_by_port(test_params->bonded_port_id);
+ ether_addr_copy(dev->data->mac_addrs, &bond_mac);
/*
* Generating packet with double VLAN header and placing it in the rx
queue.
diff --git a/app/test/virtual_pmd.c b/app/test/virtual_pmd.c
index a538c8a..b1af805 100644
--- a/app/test/virtual_pmd.c
+++ b/app/test/virtual_pmd.c
@@ -263,8 +263,8 @@ static const struct eth_dev_ops
virtual_ethdev_default_dev_ops = {
void
virtual_ethdev_start_fn_set_success(uint8_t port_id, uint8_t success)
{
- struct rte_eth_dev *dev = &rte_eth_devices[port_id];
- struct virtual_ethdev_private *dev_private = dev->data->dev_private;
+ struct virtual_ethdev_private *dev_private =
+ rte_eth_private_by_port(port_id);
struct eth_dev_ops *dev_ops = &dev_private->dev_ops
[dpdk-dev] [PATCH 3/3] bonding: use ethdev helper functions
Use rte_eth_by_port(), rte_eth_private_by_port(),
rte_eth_private_by_dev() helper functions.
Signed-off-by: Ferruh Yigit
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 10 ++--
drivers/net/bonding/rte_eth_bond_api.c| 76 +++
drivers/net/bonding/rte_eth_bond_args.c | 13 --
drivers/net/bonding/rte_eth_bond_pmd.c| 47 +++
4 files changed, 81 insertions(+), 65 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index b3b30f6..18402c2 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -854,6 +854,7 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev, uint8_t slave_id)
uint32_t total_tx_desc;
struct bond_tx_queue *bd_tx_q;
uint16_t q_id;
+ struct rte_eth_dev *dev;
/* Given slave mus not be in active list */
RTE_VERIFY(find_slave_by_id(internals->active_slaves,
@@ -882,7 +883,8 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev, uint8_t slave_id)
RTE_VERIFY(port->rx_ring == NULL);
RTE_VERIFY(port->tx_ring == NULL);
- socket_id = rte_eth_devices[slave_id].data->numa_node;
+ dev = rte_eth_by_port(slave_id);
+ socket_id = dev->data->numa_node;
element_size = sizeof(struct slow_protocol_frame) + sizeof(struct
rte_mbuf)
+ RTE_PKTMBUF_HEADROOM;
@@ -1153,7 +1155,7 @@ rte_eth_bond_8023ad_conf_get(uint8_t port_id,
if (conf == NULL)
return -EINVAL;
- bond_dev = &rte_eth_devices[port_id];
+ bond_dev = rte_eth_by_port(port_id);
bond_mode_8023ad_conf_get(bond_dev, conf);
return 0;
}
@@ -1182,7 +1184,7 @@ rte_eth_bond_8023ad_setup(uint8_t port_id,
}
}
- bond_dev = &rte_eth_devices[port_id];
+ bond_dev = rte_eth_by_port(port_id);
bond_mode_8023ad_setup(bond_dev, conf);
return 0;
@@ -1200,7 +1202,7 @@ rte_eth_bond_8023ad_slave_info(uint8_t port_id, uint8_t
slave_id,
rte_eth_bond_mode_get(port_id) != BONDING_MODE_8023AD)
return -EINVAL;
- bond_dev = &rte_eth_devices[port_id];
+ bond_dev = rte_eth_by_port(port_id);
internals = bond_dev->data->dev_private;
if (find_slave_by_id(internals->active_slaves,
diff --git a/drivers/net/bonding/rte_eth_bond_api.c
b/drivers/net/bonding/rte_eth_bond_api.c
index 8a000c8..c61ad01 100644
--- a/drivers/net/bonding/rte_eth_bond_api.c
+++ b/drivers/net/bonding/rte_eth_bond_api.c
@@ -63,7 +63,7 @@ valid_bonded_port_id(uint8_t port_id)
if (!rte_eth_dev_is_valid_port(port_id))
return -1;
- return check_for_bonded_ethdev(&rte_eth_devices[port_id]);
+ return check_for_bonded_ethdev(rte_eth_by_port(port_id));
}
int
@@ -74,7 +74,7 @@ valid_slave_port_id(uint8_t port_id)
return -1;
/* Verify that port_id refers to a non bonded port */
- if (check_for_bonded_ethdev(&rte_eth_devices[port_id]) == 0)
+ if (check_for_bonded_ethdev(rte_eth_by_port(port_id)) == 0)
return -1;
return 0;
@@ -318,14 +318,14 @@ __eth_bond_slave_add_lock_free(uint8_t bonded_port_id,
uint8_t slave_port_id)
if (valid_slave_port_id(slave_port_id) != 0)
return -1;
- bonded_eth_dev = &rte_eth_devices[bonded_port_id];
+ bonded_eth_dev = rte_eth_by_port(bonded_port_id);
internals = bonded_eth_dev->data->dev_private;
/* Verify that new slave device is not already a slave of another
* bonded device */
for (i = rte_eth_dev_count()-1; i >= 0; i--) {
- if (check_for_bonded_ethdev(&rte_eth_devices[i]) == 0) {
- temp_internals = rte_eth_devices[i].data->dev_private;
+ if (check_for_bonded_ethdev(rte_eth_by_port(i)) == 0) {
+ temp_internals = rte_eth_private_by_port(i);
for (j = 0; j < temp_internals->slave_count; j++) {
/* Device already a slave of a bonded device */
@@ -338,7 +338,7 @@ __eth_bond_slave_add_lock_free(uint8_t bonded_port_id,
uint8_t slave_port_id)
}
}
- slave_eth_dev = &rte_eth_devices[slave_port_id];
+ slave_eth_dev = rte_eth_by_port(slave_port_id);
/* Add slave details to bonded device */
slave_add(internals, slave_eth_dev);
@@ -437,7 +437,6 @@ __eth_bond_slave_add_lock_free(uint8_t bonded_port_id,
uint8_t slave_port_id)
int
rte_eth_bond_slave_add(uint8_t bonded_port_id, uint8_t slave_port_id)
{
- struct rte_eth_dev *bonded_eth_dev;
struct bond_dev_private *internals;
int retval;
@@ -446,8 +445,7 @@ rte_eth_bond_slave_add(uint8_t bonded_port_id, uint8_t
slave_port_id)
if (valid_bonded_port_id(bonded_port_id) != 0)
return -1;
-
[dpdk-dev] Network verification survey
Hello, I am a PhD student, and I research the possibilities of verification of a software dataplane applications. In order to maximize the utility of our efforts for the networking community, our team asks you to answer a couple of questions about your preferences regarding network applications verification: http://goo.gl/cL760p Please ignore this letter if you already participated in the survey in December. This short form should take no more than 2-3 minutes of your time. If you have any questions, please, e-mail me personally (arseniy.zaostrovnykh at epfl.ch). -- Respectfully, Arseniy.
[dpdk-dev] [PATCH] ixgbe: fix x550 VF tx issue
Hi Wenzhuo,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Wenzhuo Lu
> Sent: Friday, January 29, 2016 7:48 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH] ixgbe: fix x550 VF tx issue
>
> On x550, the basic tx function may not work if we use DPDK VF based on
> kernel PF. The reason is kernel PF enables a new feature "malicious driver
> detection". According to this feature, driver should create TX context
> descriptor and set the "Check Context" bit in advanced data descriptor.
> This patch add the support of "malicious driver detection" to let kernel PF
> based DPDK VF work.
Is there any way for VF to determine is MDD is enabled on PF or not?
Mailbox message or something?
If not, then I suppose for x550 VF we always have to set default txq_flags in
dev_info to PKT_TX_MALICIOUS_DRIVER_DETECT?
Which means that for X550 VF simple TX path by default will be disabled,
correct?
As alternative we probably can change tx_queue_start() for x550 VF to always
setup a dummy TCD and then make changes in TX simple path to always setup
CC bit for x550 VF.
That would allow to keep using TX simple for x550 VF , no matter is MDD is
enabled
by PF or not.
Another thing - there could be a potential slowdown with that feature:
As now TX has to occupy one extra HW context, even if no HW offload is
requested by SW,
correct?
Let say if app sends packets of 3 types:
- TCP with TX HW csum offload
- UDP with TX HW csum offload
- packets with no HW offload requested
Then on 82599 VF no PMD would need to setup TCD only fist 2 times.
But on X550 VF will need to setup new TCD for every packet.
But I suppose that is unavoidable.
>
> Although CC bit should be set in IOV mode, as tested, it's no harm to set
> CC bit in non-IVO mode. So, as PF and VF share the same code, will set CC
> bit anyway.
I don't think it totally harmless.
As I understand, if CC bit is set HW would try to apply related TC to the
packet.
If this TC was never setup - you don't know what values it will contain.
>
> Please aware there's another way, disabling MDD in PF kernel driver.
> Like this,
> >insmod ixgbe.ko MDD=0,0
>
> Signed-off-by: Wenzhuo Lu
> ---
> doc/guides/rel_notes/release_2_3.rst | 12
> drivers/net/ixgbe/ixgbe_rxtx.c | 16 ++--
> drivers/net/ixgbe/ixgbe_rxtx.h | 3 ++-
> lib/librte_ether/rte_ethdev.h| 1 +
> lib/librte_mbuf/rte_mbuf.h | 3 ++-
> 5 files changed, 31 insertions(+), 4 deletions(-)
>
> diff --git a/doc/guides/rel_notes/release_2_3.rst
> b/doc/guides/rel_notes/release_2_3.rst
> index 99de186..90f81e0 100644
> --- a/doc/guides/rel_notes/release_2_3.rst
> +++ b/doc/guides/rel_notes/release_2_3.rst
> @@ -15,6 +15,18 @@ EAL
> Drivers
> ~~~
>
> +* **ixgbe: Fixed x550 VF tx issue.**
> +
> + On x550, the basic tx function may not work if we use DPDK VF based on
> + kernel PF. The reason is kernel PF enables a new feature "malicious driver
> + detection". According to this feature, driver should create TX context
> + descriptor and set the "Check Context" bit in advanced data descriptor.
> + This patch add the support of "malicious driver detection" to let kernel PF
> + based DPDK VF work.
> +
> + Please aware there's another way, disabling MDD in PF kernel driver.
> + Like this,
> + >insmod ixgbe.ko MDD=0,0
>
> Libraries
> ~
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 52a263c..c8a7740 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -85,7 +85,8 @@
> PKT_TX_VLAN_PKT |\
> PKT_TX_IP_CKSUM |\
> PKT_TX_L4_MASK | \
> - PKT_TX_TCP_SEG)
> + PKT_TX_TCP_SEG | \
> + PKT_TX_MALICIOUS_DRIVER_DETECT)
>
> static inline struct rte_mbuf *
> rte_rxmbuf_alloc(struct rte_mempool *mp)
> @@ -564,6 +565,8 @@ ixgbe_xmit_cleanup(struct ixgbe_tx_queue *txq)
> return (0);
> }
>
> +#define DEFAULT_CTX_L2_LEN 14
Use sizeof(strutct eth_hdr) or something.
> +
> uint16_t
> ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
> uint16_t nb_pkts)
> @@ -614,11 +617,19 @@ ixgbe_xmit_pkts(void *tx_queue, struct rte_mbuf
> **tx_pkts,
>* are needed for offload functionality.
>*/
> ol_flags = tx_pkt->ol_flags;
> + if (!(txq->txq_flags & ETH_TXQ_FLAGS_NOMDD))
> + ol_flags |= PKT_TX_MALICIOUS_DRIVER_DETECT;
Probably a bit better introduce new filed inside txq: deaul_ol_flags or
something,
Then set it up depending on HW type, and then just:
ol_flags = tx_pkt->ol_flags | txq->default_ol_flags;
>
> /* If hardware offload required */
> tx_ol_req = ol_flags & IXGBE_TX_OFFLOAD_MASK;
> if (tx_ol_req) {
> - tx_offload.l2_len = tx_pkt->l2_len;
>
[dpdk-dev] [PATCH 4/5] mlx5: add support for flow director
On Fri, Jan 29, 2016 at 11:32:01AM +0100, Adrien Mazarguil wrote: > From: Yaacov Hazan > > Add support for flow director filters (RTE_FDIR_MODE_PERFECT and > RTE_FDIR_MODE_PERFECT_MAC_VLAN modes). > > This feature requires MLNX_OFED 3.2. > > Signed-off-by: Yaacov Hazan > Signed-off-by: Adrien Mazarguil > --- Hi Adrien, Yaacov, this patch raises a lot of warnings (17) with checkpatch. Can you perhaps look to see if this number can be reduced. Regards, /Bruce
[dpdk-dev] [PATCH 0/5] Add flow director and RX VLAN stripping support
On Fri, Jan 29, 2016 at 11:31:57AM +0100, Adrien Mazarguil wrote: > To preserve compatibility with Mellanox OFED 3.1, flow director and RX VLAN > stripping code is only enabled if compiled with 3.2. > This description would seem to imply that a documentation update is necessary, or at minimum a release note update, along with the code changes. Regards, /Bruce
[dpdk-dev] [PATCH 0/3] null driver improvements for testability
On Fri, Jan 29, 2016 at 04:47:58PM +, Paul Atkins wrote: > Hi Thomas, > > On 29/01/16 16:31, Thomas Monjalon wrote: > >Hi Paul, > > > >2016-01-29 16:18, Paul Atkins: > >>This patchset adds functionality to the null driver help when testing > >>a dataplane that uses dpdk. The idea is that the the dataplane can > >>have multiple null interfaces attached, and each of theses can be > >>assigned a mac address. Packets can then be injected into the null > >>drivers by adding them to a ring, giving the application complete > >>control of the packets that arrive. Packets that are sent by a null > >>driver can be stored on a ring, where the application can pick them up > >>and verify it is what was expected. To allow the application to know > >>when packets have been pulled of the rx ring, counters of the number of > >>times an rx poll has been made are kept, and these can be retrieved via > >>the existing APIs. > >I have not read your code, just read this description. > >It sounds like being a ring PMD. Have you already checked it? > >https://urldefense.proofpoint.com/v2/url?u=http-3A__dpdk.org_browse_dpdk_tree_drivers_net_ring_rte-5Feth-5Fring.c&d=CwICAg&c=IL_XqQWOjubgfqINi2jTzg&r=45ezphVDEm8OnEpH-fLWdXvR3RneLhhNZRDLQRgR6LY&m=wJLO24XFe_B0nZve6mkvocCt7fQWo3PULCTWxrC8rZk&s=bIWycJrY-PYgzkQsBeRfkl8JCHFcxRAHhHDrqRSzHYs&e= > > I hadn't seen the ring PMD. I will have a look at it and see if I can make > it do what i need. > > thanks, > Paul Hi Paul, any update on this. Your patches are still showing as pending in patchwork, but if ring pmd is more what need, we can set these patches aside as unneeded, and remove them from the patchwork merge backlog. thanks, /Bruce
[dpdk-dev] [PATCH 2/3] ring: remove duplicate fields in internal data struct
On Fri, Jan 29, 2016 at 05:16:21PM +, Ferruh Yigit wrote: > 1- Remove duplicate nb_rx/tx_queues fields from internals > 2- Remove data->rx/tx_queues allocation, whose auto allocated by > libether > 3- Remove duplicate data->rx/tx_queues[i] assignments > > Signed-off-by: Ferruh Yigit > --- > drivers/net/ring/rte_eth_ring.c | 52 > +++-- > 1 file changed, 14 insertions(+), 38 deletions(-) > Hi Ferruh, does this patch not break rte_eth_from_ring() and rte_eth_from_rings() since the "auto allocation" you refer to is only performed on eth_dev_configure, I believe. Currently, you can create an rte_ring and then use it as though it were an ethdev by calling: port_id = rte_eth_from_ring(r) With this change, I believe the user instead has to now call eth_from_ring, then do a series of configure and queue setup calls just to make the new ethdev usable. Regards. /Bruce
[dpdk-dev] [PATCH v2 3/3] examples/ethtool: add control interface support to the application
Hi Ferruh,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit
> Sent: Friday, February 12, 2016 1:46 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 3/3] examples/ethtool: add control interface
> support to the application
>
> Control interface APIs added into the sample application.
>
> To have the support corresponding kernel module (KCP) needs to be inserted.
> If kernel module is not there, application will run as it is without
> kernel control path support.
>
> When KCP module inserted, running application creates a virtual Linux
> network interface (dpdk$) per DPDK port. This interface can be used by
> traditional Linux tools.
>
> Signed-off-by: Ferruh Yigit
> ---
> doc/guides/sample_app_ug/ethtool.rst | 41
>
> examples/ethtool/ethtool-app/main.c | 10 +++--
> 2 files changed, 49 insertions(+), 2 deletions(-)
>
> diff --git a/doc/guides/sample_app_ug/ethtool.rst
> b/doc/guides/sample_app_ug/ethtool.rst
> index 4d1697e..2174288 100644
> --- a/doc/guides/sample_app_ug/ethtool.rst
> +++ b/doc/guides/sample_app_ug/ethtool.rst
> @@ -131,6 +131,47 @@ application`_. Individual call-back functions handle the
> detail
> associated with each command, which make use of the functions
> defined in the `Ethtool interface`_ to the DPDK functions.
There is ~100% code duplication between
lib/librte_ctrl_if/rte_ethtool.c and examples/ethtool/lib/rte_ethtool.c
That need to be addressed somehow.
>
> +Control Interface
> +~
> +
> +If Kernel Control Path (KCP) kernel module (rte_kcp.ko) inserted,
> +virtual interfaces created for each DPDK port for control purposes.
> +
> +Created interfaces are named as dpdk#, like:
> +
> +.. code-block:: console
> +
> +# ifconfig dpdk0; ifconfig dpdk1
> +dpdk0: flags=4099 mtu 1500
> +ether 90:e2:ba:0e:49:b9 txqueuelen 1000 (Ethernet)
> +RX packets 0 bytes 0 (0.0 B)
> +RX errors 0 dropped 0 overruns 0 frame 0
> +TX packets 0 bytes 0 (0.0 B)
> +TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> +
> +dpdk1: flags=4099 mtu 1500
> +ether 00:1b:21:76:fa:21 txqueuelen 1000 (Ethernet)
> +RX packets 0 bytes 0 (0.0 B)
> +RX errors 0 dropped 0 overruns 0 frame 0
> +TX packets 0 bytes 0 (0.0 B)
> +TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> +
> +Regular Linux commands can be issued on interfaces:
> +
> +.. code-block:: console
> +
> +# ethtool -i dpdk0
> +driver: rte_ixgbe_pmd
> +version: RTE 2.3.0-rc0
> +firmware-version:
> +expansion-rom-version:
> +bus-info: :08:00.1
> +supports-statistics: yes
> +supports-test: no
> +supports-eeprom-access: yes
> +supports-register-dump: yes
> +supports-priv-flags: no
> +
> Ethtool interface
> -
>
> diff --git a/examples/ethtool/ethtool-app/main.c
> b/examples/ethtool/ethtool-app/main.c
> index e21abcd..68b13ad 100644
> --- a/examples/ethtool/ethtool-app/main.c
> +++ b/examples/ethtool/ethtool-app/main.c
> @@ -1,7 +1,7 @@
> /*-
> * BSD LICENSE
> *
> - * Copyright(c) 2015 Intel Corporation. All rights reserved.
> + * Copyright(c) 2016 Intel Corporation. All rights reserved.
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> @@ -44,6 +44,7 @@
> #include
> #include
> #include
> +#include
>
> #include "ethapp.h"
>
> @@ -54,7 +55,6 @@
> #define PKTPOOL_EXTRA_SIZE 512
> #define PKTPOOL_CACHE 32
>
> -
> struct txq_port {
> uint16_t cnt_unsent;
> struct rte_mbuf *buf_frames[MAX_BURST_LENGTH];
> @@ -254,6 +254,8 @@ static int slave_main(__attribute__((unused)) void
> *ptr_data)
> }
> rte_spinlock_unlock(&ptr_port->lock);
> } /* end for( idx_port ) */
> + rte_eth_control_interface_process_msg(
> + RTE_ETHTOOL_CTRL_IF_PROCESS_MSG, 0);
As I can see, few problems here:
1. Race condition was introduced between slave_main() and ethapp_main() -
both can try to do dev_start()/dev_stop() or other intrusive things over the
same port
simultaneously.
2. Better to avoid calling rte_eth_control_interface_process_msg() from RT code
path
that doing RX/TX packets - it is too slow for that.
3. Right now - if you'll have to postpone any RX/TX on any ports when calling
rte_eth_control_interface_process_msg().
As it can't distinguish message for what particular port it is going to
process.
Need to address it somehow - either add function that would return current
message port_id,
or introduce a sync callback function and add is a parameter for
rte_eth_control_interface_process_msg() ,
or probably someth
[dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ferruh Yigit > Sent: Friday, February 12, 2016 1:46 PM > To: dev at dpdk.org > Subject: [dpdk-dev] [PATCH v2 2/3] rte_ctrl_if: add control interface library > > This library gets control messages form kernelspace and forwards them to > librte_ether and returns response back to the kernelspace. > > Library does: > 1) Trigger Linux virtual interface creation > 2) Initialize the netlink socket communication > 3) Provides process() API to the application that does processing the > received messages > > This library requires corresponding kernel module to be inserted. > > Signed-off-by: Ferruh Yigit > > --- > > v2: > * User rtnetlink to create interfaces. > * Add more ethtool support: get/set ringparam, set pauseparam. > * return defined error instead of hardcoded value > --- > MAINTAINERS| 1 + > config/common_linuxapp | 3 +- > doc/api/doxy-api-index.md | 3 +- > doc/api/doxy-api.conf | 1 + > doc/guides/rel_notes/release_16_04.rst | 9 + > lib/Makefile | 3 +- > lib/librte_ctrl_if/Makefile| 58 > lib/librte_ctrl_if/rte_ctrl_if.c | 385 > lib/librte_ctrl_if/rte_ctrl_if.h | 115 > lib/librte_ctrl_if/rte_ctrl_if_version.map | 9 + > lib/librte_ctrl_if/rte_ethtool.c | 450 > + > lib/librte_ctrl_if/rte_ethtool.h | 54 > lib/librte_ctrl_if/rte_nl.c| 274 ++ > lib/librte_ctrl_if/rte_nl.h| 49 > lib/librte_eal/common/include/rte_log.h| 3 +- > mk/rte.app.mk | 3 +- > 16 files changed, 1415 insertions(+), 5 deletions(-) > create mode 100644 lib/librte_ctrl_if/Makefile > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.c > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if.h > create mode 100644 lib/librte_ctrl_if/rte_ctrl_if_version.map > create mode 100644 lib/librte_ctrl_if/rte_ethtool.c > create mode 100644 lib/librte_ctrl_if/rte_ethtool.h > create mode 100644 lib/librte_ctrl_if/rte_nl.c > create mode 100644 lib/librte_ctrl_if/rte_nl.h > > diff --git a/MAINTAINERS b/MAINTAINERS > index 09c56c7..91c98bc 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -256,6 +256,7 @@ F: doc/guides/sample_app_ug/kernel_nic_interface.rst > Linux KCP > M: Ferruh Yigit > F: lib/librte_eal/linuxapp/kcp/ > +F: lib/librte_ctrl_if/ > > Linux AF_PACKET > M: John W. Linville > diff --git a/config/common_linuxapp b/config/common_linuxapp > index 2f4eb1d..4bcd508 100644 > --- a/config/common_linuxapp > +++ b/config/common_linuxapp > @@ -1,6 +1,6 @@ > # BSD LICENSE > # > -# Copyright(c) 2010-2015 Intel Corporation. All rights reserved. > +# Copyright(c) 2010-2016 Intel Corporation. All rights reserved. > # All rights reserved. > # > # Redistribution and use in source and binary forms, with or without > @@ -501,6 +501,7 @@ CONFIG_RTE_KNI_VHOST_DEBUG_TX=n > # > CONFIG_RTE_KCP_KMOD=y > CONFIG_RTE_KCP_KO_DEBUG=n > +CONFIG_RTE_LIBRTE_CTRL_IF=y > > # > # Compile vhost library > diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md > index 7a91001..214d16e 100644 > --- a/doc/api/doxy-api-index.md > +++ b/doc/api/doxy-api-index.md > @@ -149,4 +149,5 @@ There are many libraries, so their headers may be grouped > by topics: >[common] (@ref rte_common.h), >[ABI compat] (@ref rte_compat.h), >[keepalive] (@ref rte_keepalive.h), > - [version](@ref rte_version.h) > + [version](@ref rte_version.h), > + [control interface] (@ref rte_ctrl_if.h) > diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf > index 57e8b5d..fd69bf1 100644 > --- a/doc/api/doxy-api.conf > +++ b/doc/api/doxy-api.conf > @@ -39,6 +39,7 @@ INPUT = doc/api/doxy-api-index.md \ >lib/librte_cmdline \ >lib/librte_compat \ >lib/librte_cryptodev \ > + lib/librte_ctrl_if \ >lib/librte_distributor \ >lib/librte_ether \ >lib/librte_hash \ > diff --git a/doc/guides/rel_notes/release_16_04.rst > b/doc/guides/rel_notes/release_16_04.rst > index 27fc624..1b1d34c 100644 > --- a/doc/guides/rel_notes/release_16_04.rst > +++ b/doc/guides/rel_notes/release_16_04.rst > @@ -39,6 +39,14 @@ This section should contain new features added in this > release. Sample format: > >Enabled virtio 1.0 support for virtio pmd driver. > > +* **Control interface support added.** > + > + To enable controlling DPDK ports by common Linux tools. > + Following modules added to DPDK: > + > + * librte_ctrl_if library > + * librte_eal/linuxap
[dpdk-dev] x86_64-native-linuxapp-clang compilation broken?
On Wed, Feb 17, 2016 at 11:07:40AM +, De Lara Guarch, Pablo wrote: > It looks like old versions of clang are not able to identify correctly the > newer CPUs: > > LLVM (http://llvm.org/): > LLVM version 3.6.2 > > Optimized build. > Built Aug 18 2015 (08:39:18). > Default target: x86_64-pc-linux-gnu > Host CPU: x86-64 > > > LLVM (http://llvm.org/): > LLVM version 3.7.0 > Optimized build. > Built Jan 22 2016 (17:39:46). > Default target: x86_64-redhat-linux-gnu > Host CPU: broadwell > > I will submit a patch adding a note in known issues section, unless anybody > knows > how to fix this in our side (as far as I know, it is a clang issue). > > Thanks, > Pablo Hello Pablo, Just having some explanation of the root cause is a great start even if it can't necessarily be fixed in DPDK. I will install clang 3.7.X and retry it. Matthew.
[dpdk-dev] [PATCH v8 0/5] add virtio offload support in us-vhost
2016-02-05 15:31, Jijiang Liu: > Adds virtio offload support in us-vhost. > > The patch set adds the feature negotiation of checksum and TSO between > us-vhost and vanilla Linux virtio guest, and add these offload features > support in the vhost lib, and change vhost sample to test them. > > In short, this patch set supports the followings, > > - DPDK vhost CSUM & TSO for VM2NIC case > > - CSUM and TSO support between legacy virtio-net and DPDK vhost for > VM2VM and NIC2VM cases. Applied, thanks Please check how titles and release notes have been reworded. It may help for next times.
[dpdk-dev] [PATCH 0/5 for 2.3] vhost rxtx refactor
Hi Yuanhan, 2015-12-03 14:06, Yuanhan Liu: > Vhost rxtx code is derived from vhost-switch example, which is very > likely the most messy code in DPDK. Unluckily, the move also brings > over the bad merits: twisted logic, bad comments. > > When I joined this team firstly, I was quite scared off by the messy > and long vhost rxtx code. While adding the vhost-user live migration > support, that I have to make fews changes to it, I then ventured to > look at it again, to understand it better, in the meantime, to see if > I can refactor it. > > And, here you go. There were several comments and a typo detected. Please what is the status of this patchset?
