[dpdk-dev] how to search this mailing list? is gmane link archive broken?
Hey, You can try "site:" Google search operator, i.e. try to google: site:dpdk.org/ml/archives/dev/ Regards, Andriy On Mon, Nov 7, 2016 at 6:12 PM, Montorsi, Francesco wrote: > 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 > > > -- Andriy Berestovskyy
[dpdk-dev] [PATCH] doc: announce API change for virtual device initialization
Hey folks, > On 28 Jul 2016, at 17:47, De Lara Guarch, Pablo intel.com> wrote: > Fair enough. So you mean to use rte_eth_dev_attach in ethdev library and > a similar function in cryptodev library? There is a rte_eth_dev_get_port_by_name() which gets the port id right after the rte_eal_vdev_init() call. You might consider the same for the crypto... Regards, Andriy
[dpdk-dev] [dpdk-announce] DPDK 16.07 released
On behalf of contributors, thank you so much all the reviewers, maintainers and un tr?s grand merci ? Thomas for your great job, help and patience ;) Regards, Andriy > On 28 Jul 2016, at 23:39, Thomas Monjalon > wrote: > > Once again, a great release from the impressive DPDK community: >http://fast.dpdk.org/rel/dpdk-16.07.tar.xz > > The statistics are awesome: >955 patches from 115 authors >839 files changed, 127162 insertions(+), 24668 deletions(-) > > There are 50 new contributors > (including authors, reviewers and testers): > Thanks to Adam Bynes, Ajit Khaparde, Akhil Goyal, Alex Wang, > Amin Tootoonchian, Anupam Kapoor, Bj?rn T?pel, Chaeyong Chong, > David Christensen, Dmitriy Yakovlev, Dumitru Ceara, Eoin Breen, > Fengtian Guo, Guruprasad Mukundarao, Hiroyuki Mikita, Ian Stokes, > Ido Barnea, Jeff Guo, John Guzik, Juan Antonio Montesinos, > Juhamatti Kuusisaari, Maxime Coquelin, Michael Habibi, Nikhil Rao, > Patrik Andersson, Radoslaw Biernacki, Raslan Darawsheh, Ricardo Salveti, > Ricky Li, Ronghua Zhang, Sameh Gobriel, Sankar Chokkalingam, > Sergey Dyasly, Shreyansh Jain, Slawomir Rosek, Sony Chacko, Stephen Hurd, > Thadeu Lima de Souza Cascardo, Thomas Petazzoni, Tiwei Bie, > Vasily Philipov, Vincent Li, Wei Dai, WeiJie Zhuang, Wei Shen, > Xiaoban Wu, Xueqin Lin, Yari Adan Petralanda, Yongseok Koh, Zyta Szpak. > > These new contributors are associated with these domain names: > 6wind.com, awakenetworks.com, broadcom.com, caviumnetworks.com, > cisco.com, coriant.com, ericsson.com, free-electrons.com, gmail.com, > berkeley.edu, intel.com, linaro.org, mellanox.com, nxp.com, outlook.com, > qlogic.com, redhat.com, samsung.com, schaman.hu, semihalf.com, > shieldxnetworks.com, uml.edu, vmware.com. > > Some highlights: >* mempool reworked >* KASUMI crypto >* driver bnxt >* driver for ThunderX >* virtio for POWER8 >* virtio-user for containers >* vhost-user client mode >* packet capture framework > > More details in the release notes: >http://dpdk.org/doc/guides/rel_notes/release_16_07.html > > The new features for the 16.11 cycle must be submitted before August 28. > The features properly reviewed and approved before October will be part > of the next release which will be a bit shorter (3 months) than before. > > If you read until this line, please take few more minutes to fill out > this survey: http://surveymonkey.com/r/DPDK_Community_Survey > > Thanks everyone
[dpdk-dev] [PATCH] doc: announce KNI ethtool removal
Hi folks, Just to clarify. Thomas is talking about removing just the KNI ethtool (i.e. lib/librte_eal/linuxapp/kni/ethtool/*). The major functionality of those 45K lines of code is to get the same MAC address on the KNI interface and the underlying igb/ixgbe NIC. At the moment the rest of the DPDK eth devices work fine without the KNI ethtool. The workaround is very simple: use ifconfig or ip tool to set the same MAC you have on your NIC. Put it into your network configuration to make it permanent. Examples: ifconfig vEth0_0 hw ether or ip link set vEth0_0 address or in /etc/network/interfaces under the "iface vEth0_0" section add the following: hwaddress Andriy On Thu, Jul 21, 2016 at 10:54 PM, Jay Rolette wrote: > On Thu, Jul 21, 2016 at 3:32 PM, Thomas Monjalon 6wind.com> > wrote: > >> 2016-07-21 13:20, Jay Rolette: >> > On Thu, Jul 21, 2016 at 10:33 AM, Ferruh Yigit >> > wrote: >> > > KNI ethtool is functional and maintained, and it may have users! >> > > >> > > Why just removing it, specially without providing an alternative? >> > > Is is good time to discuss KCP again? >> > >> > Yes, my product uses it. >> >> Your product uses what? KCP? KNI? KNI ethtool? >> > > Sorry, that wasn't very clear. It uses KNI + ifconfig to configure the > device/interface in Linux. I'm assuming the "ethtool" bits under discussion > are the same things that make ifconfig work with KNI to the limited extent > it does. > >> Seems like we are back to the same discussion we >> > had a few months ago about the KNI situation... >> > >> > It shouldn't be removed unless there is a replacement, ideally one that >> > works with the normal Linux tools like every other network device. >> >> This ethtool module works only for igb and ixgbe! >> There is already no replacement for other drivers. >> Who works on a replacement? >> > > Ferruh submitted KCP previously, but you guys didn't like the fact that it > was a kernel module. IIRC, one of the gains from that was simplified > maintenance because you didn't need driver specific support for KNI. > Assuming he's still willing to beat it into shape, we have something that > is already most of the way there. > > If people are going to continue to block it because it is a kernel module, > then IMO, it's better to leave the existing support on igx / ixgbe in place > instead of stepping backwards to zero support for ethtool. > >> While the code wasn't ready at the time, it was a definite improvement >> over what >> > we have with KNI today. >> -- Andriy Berestovskyy
[dpdk-dev] Couple of PMD questions
ize parameter of >> > > > rte_pktmbuf_pool_create(): >> > > > >> > > > "Size of data buffer in each mbuf, including RTE_PKTMBUF_HEADROOM." >> > > > >> > > > >> > > > If I support a max frame size of 9216 bytes (exactly a 1K multiple >> > > > to >> > > make >> > > > the NIC happy), then max_rx_pkt_len is going to be 9216 and >> > > data_room_size >> > > > will be 9216 + RTE_PKTMBUF_HEADROOM. >> > > > >> > > > ixgbe_dev_rx_init() will calculate normalize that back to 9216, >> > > > which >> > > will >> > > > fail the dual VLAN length check. The really nasty part about that is >> > > > it >> > > has >> > > > a side-effect of enabling scattered RX regardless of the fact that I >> > > didn't >> > > > enable scattered RX in dev_conf.rxmode. >> > > > >> > > > The code in the e1000 PMD is similar, so nothing unique to ixgbe. >> > > > >> > > > Is that check correct? It seems wrong to be adding space for q-in-q >> > > > on >> > > top >> > > > of your specified max frame size... >> > > >> > > The issue here is what the correct behaviour needs to be. If we have >> > > the >> > > user >> > > specify the maximum frame size including all vlan tags, then we hit >> > > the >> > > problem >> > > where we have to subtract the VLAN tag sizes when writing the value to >> > > the >> > > NIC. >> > > In that case, we will hit a problem where we get a e.g. 9210 byte >> > > frame - >> > > to >> > > reuse your example - without any VLAN tags, which will be rejected by >> > > the >> > > hardware as being oversized. If we don't do the subtraction, and we >> > > get the >> > > same 9210 byte packet with 2 VLAN tags on it, the hardware will accept >> > > it >> > > and >> > > then split it across multiple descriptors because the actual DMA size >> > > is >> > > 9218 bytes. >> > > >> > >> > As an app developer, I didn't realize the max frame size didn't include >> > VLAN tags. I expected max frame size to be the size of the ethernet >> > frame >> > on the wire, which I would expect to include space used by any VLAN or >> > MPLS >> > tags. >> > >> > Is there anything in the docs or example apps about that? I did some >> > digging as I was debugging this and didn't notice it, but entirely >> > possible >> > I just missed it. >> > >> > >> > > I'm not sure there is a works-in-all-cases solution here. >> > > >> > >> > Andriy's suggestion seems like it points in the right direction. >> > >> > From an app developer point of view, I'd expect to have a single max >> > frame >> > size value to track and the APIs should take care of any adjustments >> > required internally. Maybe have rte_pktmbuf_pool_create() add the >> > additional bytes when it calls rte_mempool_create() under the covers? >> > Then >> > it's nice and clean for the API without unexpected side-effects. >> > >> >> It will still have unintended side-effects I think, depending on the >> resolution >> of the NIC buffer length paramters. For drivers like ixgbe or e1000, the >> mempool >> create call could potentially have to add an additional 1k to each buffer >> just >> to be able to store the extra eight bytes. > > > The comments in the ixgbe driver say that the value programmed into SRRCTL > must be on a 1K boundary. Based on your previous response, it sounded like > the NIC ignores that limit for VLAN tags, hence the check for the extra 8 > bytes on the mbuf element size. Are you worried about the size resolution on > mempool elements? > > Sounds like I've got to go spend some quality time in the NIC data sheets... > Maybe I should back up and just ask the higher level question: > > What's the right incantation in both the dev_conf structure and in creating > the mbuf pool to support jumbo frames of some particular size on the wire, > with or without VLAN tags, without requiring scattered_rx support in an app? > > Thanks, > Jay -- Andriy Berestovskyy
[dpdk-dev] Couple of PMD questions
Hi Jay, On Tue, Apr 19, 2016 at 10:16 PM, Jay Rolette wrote: > Should the driver error out in that case instead of only "sort of" working? +1, we hit the same issue. Error or log message would help. > If I support a max frame size of 9216 bytes (exactly a 1K multiple to make > the NIC happy), then max_rx_pkt_len is going to be 9216 and data_room_size > will be 9216 + RTE_PKTMBUF_HEADROOM. Try to set max_rx_pkt_len <= 9K - 8 and mempool element size to 9K + headroom + size of structures. > Is that check correct? Datasheet says: The MFS does not include the 4 bytes of the VLAN header. Packets with VLAN header can be as large as MFS + 4. When double VLAN is enabled, the device adds 8 to the MFS for any packets. Regards, Andriy
[dpdk-dev] Questions about reading/writing/modifying packet header.
Hi Ick-Sung,
Please see inline.
On Mon, Apr 18, 2016 at 2:14 PM, ??? wrote:
> If I take an example, the worker assignment method using (not %) in
> load balancing was not fixed yet.
If the code works, there is nothing to fix, right? ;)
> Question #1) I would like to know how can I read/write/modify
> TCP/UDP/ICMP/IGMP/... headers from packet in rte_mbuf.
> I will really appreciate if I can be given an example code. I guess it
> would be somewhat complex.
For an example please have a look at parse_ethernet() in test-pmd:
http://dpdk.org/browse/dpdk/tree/app/test-pmd/csumonly.c#n171
The example usage is in the same file:
eth_hdr = rte_pktmbuf_mtod(m, struct ether_hdr *);
parse_ethernet(eth_hdr, );
l3_hdr = (char *)eth_hdr + info.l2_len;
if (info.l4_proto == IPPROTO_UDP) {
udp_hdr = (struct udp_hdr *)((char *)l3_hdr + info.l3_len);
udp_hdr->dst_port = ...
}
Then you might need to recalculate the L4 checksum, so have a look at
rte_ipv4_udptcp_cksum().
> Question #2) The IP checksum does not include 6 the ptr. 6 th ptr (ptr16[5])
> is missing in the example code. Is it right?
> ( ip_cksum += ptr16[5]; in the following code.)
The code seems fine, ptr16[5] is the checksum itself. It should be
zero, so we can skip it.
There is a users at dpdk.org mailing list now, so please use it for your
further questions. Here is the link for your convenience:
http://dpdk.org/ml
Regards,
Andriy
[dpdk-dev] About bond api lacp problem.
Hi,
Basically, you have to make sure you call rte_eth_tx_burst() every 100
ms in your forwarding loop. Here is such an example:
const uint64_t bond_tx_cycles = (rte_get_timer_hz() + MS_PER_S - 1) *
100 / MS_PER_S;
uint64_t cur_bond_cycles, diff_cycles;
uint64_t last_bond_tx_cycles = 0;
/* Inside your forwarding loop: */
cur_bond_cycles = rte_get_timer_cycles();
diff_cycles = cur_bond_cycles - last_bond_tx_cycles;
if (diff_cycles > bond_tx_cycles) {
last_bond_tx_cycles = cur_bond_cycles;
rte_eth_tx_burst(bond_port_id, 0, NULL, 0);
}
There is a user at dpdk.org mailing list, please address such questions there.
Regards,
Andriy
On Sat, Apr 16, 2016 at 11:41 AM, yangbo wrote:
> Hi,
>
> How to understand bond api comments:
>
> for LACP mode to work the rx/tx burst functions must be invoked at least once
> every 100ms, otherwise the out-of-band LACP messages will not be handled with
> the expected latency and this may cause the link status to be incorrectly
> marked as down or failure to correctly negotiate with peers.
>
>
> can any one give me example or more detail info ?
>
> I am extremely grateful for it.
--
Andriy Berestovskyy
[dpdk-dev] [PKTGEN] additional terminal IO question
Hi Matthew, Every software has bugs. pktgen is a great tool and we appreciate it as is. I would prefer we discuss a patch rather that questioning a functionality implemented way ago... Andriy On Sat, Jan 23, 2016 at 3:48 AM, Matthew Hall wrote: > On Thu, Jan 21, 2016 at 05:35:00PM +0200, Arnon Warshavsky wrote: >> Keith, >> For the record, on my end (can only speak for myself) this is not a real >> problem. >> I work around it by using a different theme and live with it happily ever >> after. >> I just provided the input since I encountered it. >> >> /Arnon > > For me, breaking stuff with a black background to gain questionably useful > colors and/or themes seems like more overhead for cognition of the code for > not much benefit. > > This is going to break the tool people who use a Linux standard framebuffer > with no X also, isn't it? > > Matthew. -- Andriy Berestovskyy
[dpdk-dev] [PATCH] bonding: fix reordering of IP fragments
On Tue, Dec 8, 2015 at 3:47 PM, Andriy Berestovskyy wrote: > Fragmented IPv4 packets have no TCP/UDP headers, so we hashed > random data introducing reordering of the fragments. Signed-off-by: Andriy Berestovskyy
[dpdk-dev] [PATCH] bond: fix LACP mempool size
On Tue, Dec 8, 2015 at 2:23 PM, Andriy Berestovskyy wrote: > The following messages might appear after some idle time: > "PMD: Failed to allocate LACP packet from pool" > > The fix ensures the mempool size is greater than the sum > of TX descriptors. Signed-off-by: Andriy Berestovskyy
[dpdk-dev] [PATCH] bonding: fix reordering of IP fragments
Fragmented IPv4 packets have no TCP/UDP headers, so we hashed
random data introducing reordering of the fragments.
---
drivers/net/bonding/rte_eth_bond_pmd.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_pmd.c
b/drivers/net/bonding/rte_eth_bond_pmd.c
index 8f84ec1..b1373c6 100644
--- a/drivers/net/bonding/rte_eth_bond_pmd.c
+++ b/drivers/net/bonding/rte_eth_bond_pmd.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -552,17 +553,20 @@ xmit_l34_hash(const struct rte_mbuf *buf, uint8_t
slave_count)
l3hash = ipv4_hash(ipv4_hdr);
- ip_hdr_offset = (ipv4_hdr->version_ihl & IPV4_HDR_IHL_MASK) *
- IPV4_IHL_MULTIPLIER;
-
- if (ipv4_hdr->next_proto_id == IPPROTO_TCP) {
- tcp_hdr = (struct tcp_hdr *)((char *)ipv4_hdr +
- ip_hdr_offset);
- l4hash = HASH_L4_PORTS(tcp_hdr);
- } else if (ipv4_hdr->next_proto_id == IPPROTO_UDP) {
- udp_hdr = (struct udp_hdr *)((char *)ipv4_hdr +
- ip_hdr_offset);
- l4hash = HASH_L4_PORTS(udp_hdr);
+ /* there is no L4 header in fragmented packet */
+ if (likely(rte_ipv4_frag_pkt_is_fragmented(ipv4_hdr) == 0)) {
+ ip_hdr_offset = (ipv4_hdr->version_ihl &
IPV4_HDR_IHL_MASK) *
+ IPV4_IHL_MULTIPLIER;
+
+ if (ipv4_hdr->next_proto_id == IPPROTO_TCP) {
+ tcp_hdr = (struct tcp_hdr *)((char *)ipv4_hdr +
+ ip_hdr_offset);
+ l4hash = HASH_L4_PORTS(tcp_hdr);
+ } else if (ipv4_hdr->next_proto_id == IPPROTO_UDP) {
+ udp_hdr = (struct udp_hdr *)((char *)ipv4_hdr +
+ ip_hdr_offset);
+ l4hash = HASH_L4_PORTS(udp_hdr);
+ }
}
} else if (rte_cpu_to_be_16(ETHER_TYPE_IPv6) == proto) {
struct ipv6_hdr *ipv6_hdr = (struct ipv6_hdr *)
--
1.9.1
[dpdk-dev] [PATCH] bond: fix LACP mempool size
The following messages might appear after some idle time:
"PMD: Failed to allocate LACP packet from pool"
The fix ensures the mempool size is greater than the sum
of TX descriptors.
---
drivers/net/bonding/rte_eth_bond_8023ad.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/bonding/rte_eth_bond_8023ad.c
b/drivers/net/bonding/rte_eth_bond_8023ad.c
index ee2964a..b3b30f6 100644
--- a/drivers/net/bonding/rte_eth_bond_8023ad.c
+++ b/drivers/net/bonding/rte_eth_bond_8023ad.c
@@ -851,6 +851,9 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev, uint8_t slave_id)
char mem_name[RTE_ETH_NAME_MAX_LEN];
int socket_id;
unsigned element_size;
+ uint32_t total_tx_desc;
+ struct bond_tx_queue *bd_tx_q;
+ uint16_t q_id;
/* Given slave mus not be in active list */
RTE_VERIFY(find_slave_by_id(internals->active_slaves,
@@ -884,14 +887,17 @@ bond_mode_8023ad_activate_slave(struct rte_eth_dev
*bond_dev, uint8_t slave_id)
element_size = sizeof(struct slow_protocol_frame) + sizeof(struct
rte_mbuf)
+ RTE_PKTMBUF_HEADROOM;
-/* How big memory pool should be? If driver will not
- * free packets quick enough there will be ENOMEM in tx_machine.
- * For now give 511 pkts * max number of queued TX packets per slave.
- * Hope it will be enough. */
+ /* The size of the mempool should be at least:
+* the sum of the TX descriptors + BOND_MODE_8023AX_SLAVE_TX_PKTS */
+ total_tx_desc = BOND_MODE_8023AX_SLAVE_TX_PKTS;
+ for (q_id = 0; q_id < bond_dev->data->nb_rx_queues; q_id++) {
+ bd_tx_q = (struct
bond_tx_queue*)bond_dev->data->tx_queues[q_id];
+ total_tx_desc += bd_tx_q->nb_tx_desc;
+ }
+
snprintf(mem_name, RTE_DIM(mem_name), "slave_port%u_pool", slave_id);
port->mbuf_pool = rte_mempool_create(mem_name,
- BOND_MODE_8023AX_SLAVE_TX_PKTS * 512 - 1,
- element_size,
+ total_tx_desc, element_size,
RTE_MEMPOOL_CACHE_MAX_SIZE >= 32 ? 32 :
RTE_MEMPOOL_CACHE_MAX_SIZE,
sizeof(struct rte_pktmbuf_pool_private), rte_pktmbuf_pool_init,
NULL, rte_pktmbuf_init, NULL, socket_id, MEMPOOL_F_NO_SPREAD);
@@ -932,12 +938,12 @@ bond_mode_8023ad_deactivate_slave(struct rte_eth_dev
*bond_dev,
struct port *port;
uint8_t i;
- /* Given slave mus be in active list */
+ /* Given slave must be in active list */
RTE_VERIFY(find_slave_by_id(internals->active_slaves,
internals->active_slave_count, slave_id) <
internals->active_slave_count);
/* Exclude slave from transmit policy. If this slave is an aggregator
-* make all aggregated slaves unselected to force sellection logic
+* make all aggregated slaves unselected to force selection logic
* to select suitable aggregator for this port. */
for (i = 0; i < internals->active_slave_count; i++) {
port = _8023ad_ports[internals->active_slaves[i]];
@@ -1095,7 +1101,7 @@ bond_mode_8023ad_handle_slow_pkt(struct bond_dev_private
*internals,
goto free_out;
}
- /* Setup marker timer. Do it in loop in case concurent access.
*/
+ /* Setup marker timer. Do it in loop in case concurrent access.
*/
do {
old_marker_timer = port->rx_marker_timer;
if (!timer_is_expired(_marker_timer)) {
--
1.9.1
[dpdk-dev] [PATCH 6/8] bond: handle slaves with fewer queues than bonding device
q_id < nb_rx_queues ; q_id++) {
> bd_rx_q = (struct bond_rx_queue
> *)bonded_eth_dev->data->rx_queues[q_id];
>
> errval = rte_eth_rx_queue_setup(slave_eth_dev->data->port_id,
> q_id,
> @@ -1361,7 +1449,7 @@ slave_configure(struct rte_eth_dev *bonded_eth_dev,
> /* Setup Tx Queues */
> /* Use existing queues, if any */
> for (q_id = slave_eth_dev->data->nb_tx_queues;
> -q_id < bonded_eth_dev->data->nb_tx_queues; q_id++) {
> +q_id < nb_tx_queues ; q_id++) {
> bd_tx_q = (struct bond_tx_queue
> *)bonded_eth_dev->data->tx_queues[q_id];
>
> errval = rte_eth_tx_queue_setup(slave_eth_dev->data->port_id,
> q_id,
> @@ -1440,7 +1528,8 @@ bond_ethdev_slave_link_status_change_monitor(void
> *cb_arg);
>
> void
> slave_add(struct bond_dev_private *internals,
> - struct rte_eth_dev *slave_eth_dev)
> + struct rte_eth_dev *slave_eth_dev,
> + const struct rte_eth_dev_info *slave_dev_info)
> {
> struct bond_slave_details *slave_details =
> >slaves[internals->slave_count];
> @@ -1448,6 +1537,20 @@ slave_add(struct bond_dev_private *internals,
> slave_details->port_id = slave_eth_dev->data->port_id;
> slave_details->last_link_status = 0;
>
> + uint16_t bond_nb_rx_queues =
> + rte_eth_devices[internals->port_id].data->nb_rx_queues;
> + uint16_t bond_nb_tx_queues =
> + rte_eth_devices[internals->port_id].data->nb_tx_queues;
> +
> + slave_details->nb_rx_queues =
> + bond_nb_rx_queues > slave_dev_info->max_rx_queues
> + ? slave_dev_info->max_rx_queues
> + : bond_nb_rx_queues;
> + slave_details->nb_tx_queues =
> + bond_nb_tx_queues > slave_dev_info->max_tx_queues
> + ? slave_dev_info->max_tx_queues
> + : bond_nb_tx_queues;
> +
> /* If slave device doesn't support interrupts then we need to enabled
> * polling to monitor link status */
> if (!(slave_eth_dev->data->dev_flags & RTE_PCI_DRV_INTR_LSC)) {
> diff --git a/drivers/net/bonding/rte_eth_bond_private.h
> b/drivers/net/bonding/rte_eth_bond_private.h
> index 6c47a29..02f6de1 100644
> --- a/drivers/net/bonding/rte_eth_bond_private.h
> +++ b/drivers/net/bonding/rte_eth_bond_private.h
> @@ -101,6 +101,8 @@ struct bond_slave_details {
> uint8_t link_status_poll_enabled;
> uint8_t link_status_wait_to_complete;
> uint8_t last_link_status;
> + uint16_t nb_rx_queues;
> + uint16_t nb_tx_queues;
> /**< Port Id of slave eth_dev */
> struct ether_addr persisted_mac_addr;
>
> @@ -240,7 +242,8 @@ slave_remove(struct bond_dev_private *internals,
>
> void
> slave_add(struct bond_dev_private *internals,
> - struct rte_eth_dev *slave_eth_dev);
> + struct rte_eth_dev *slave_eth_dev,
> + const struct rte_eth_dev_info *slave_dev_info);
>
> uint16_t
> xmit_l2_hash(const struct rte_mbuf *buf, uint8_t slave_count);
> --
> 2.1.4
>
--
Andriy Berestovskyy
[dpdk-dev] how to get driver name for a given port ID
Hi Francesco, You're on the right track. Please note that struct rte_eth_dev_info also has max_rx_queues field - maximum number of RX queues the NIC supports. Regards, Andriy On Tue, Oct 27, 2015 at 10:59 AM, Montorsi, Francesco wrote: > 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 > -- Andriy Berestovskyy
[dpdk-dev] ixgbe: ierrors counter spuriously increasing in DPDK 2.1
Hi Martin, We agreed on the main point: it's an issue. IMO the implementation details are up to Maryam. There have been few patches, so I guess it will be fixed in 2.2. Andriy On Thu, Oct 22, 2015 at 9:46 AM, Martin Weiser wrote: > Hi Andriy, > > thank you for pointing this discussion out to me. I somehow missed it. > Unfortunately it looks like the discussion stopped after Maryam made a > good proposal so I will vote in on that and hopefully get things started > again. > > Best regards, > Martin > > > > On 21.10.15 17:53, Andriy Berestovskyy wrote: >> Yes Marcin, >> The issue was discussed here: >> http://dpdk.org/ml/archives/dev/2015-September/023229.html >> >> You can either fix the ierrors in ixgbe_dev_stats_get() or implement a >> workaround in your app getting the extended statistics and counting >> out some of extended counters from the ierrors. >> >> Here is an example: >> https://github.com/Juniper/contrail-vrouter/commit/72f6ca05ac81d0ca5e7eb93c6ffe7a93648c2b00#diff-99c1f65a00658c7d38b3d1b64cb5fd93R1306 >> >> Regards, >> Andriy >> >> On Wed, Oct 21, 2015 at 10:38 AM, Martin Weiser >> wrote: >>> Hi, >>> >>> with DPDK 2.1 we are seeing the ierrors counter increasing for 82599ES >>> ports without reason. Even directly after starting test-pmd the error >>> counter immediately is 1 without even a single packet being sent to the >>> device: >>> >>> ./testpmd -c 0xfe -n 4 -- --portmask 0x3 --interactive >>> ... >>> testpmd> show port stats all >>> >>> NIC statistics for port 0 >>> >>> RX-packets: 0 RX-missed: 0 RX-bytes: 0 >>> RX-badcrc: 0 RX-badlen: 0 RX-errors: 1 >>> RX-nombuf: 0 >>> TX-packets: 0 TX-errors: 0 TX-bytes: 0 >>> >>> >>> >>> NIC statistics for port 1 >>> >>> RX-packets: 0 RX-missed: 0 RX-bytes: 0 >>> RX-badcrc: 0 RX-badlen: 0 RX-errors: 1 >>> RX-nombuf: 0 >>> TX-packets: 0 TX-errors: 0 TX-bytes: 0 >>> >>> >>> >>> >>> When packet forwarding is started the ports perform normally and >>> properly forward all packets but a huge number of ierrors is counted: >>> >>> testpmd> start >>> ... >>> testpmd> show port stats all >>> >>> NIC statistics for port 0 >>> >>> RX-packets: 9011857RX-missed: 0 RX-bytes: 5020932992 >>> RX-badcrc: 0 RX-badlen: 0 RX-errors: 9011753 >>> RX-nombuf: 0 >>> TX-packets: 9026250TX-errors: 0 TX-bytes: 2922375542 >>> >>> >>> >>> NIC statistics for port 1 >>> #### >>> RX-packets: 9026250RX-missed: 0 RX-bytes: 2922375542 >>> RX-badcrc: 0 RX-badlen: 0 RX-errors: 9026138 >>> RX-nombuf: 0 >>> TX-packets: 9011857TX-errors: 0 TX-bytes: 5020932992 >>> >>> >>> >>> >>> When running the exact same test with DPDK version 2.0 no ierrors are >>> reported. >>> Is anyone else seeing strange ierrors being reported for Intel Niantic >>> cards with DPDK 2.1? >>> >>> Best regards, >>> Martin >>> >> >> > > -- Andriy Berestovskyy
[dpdk-dev] ixgbe: ierrors counter spuriously increasing in DPDK 2.1
Yes Marcin, The issue was discussed here: http://dpdk.org/ml/archives/dev/2015-September/023229.html You can either fix the ierrors in ixgbe_dev_stats_get() or implement a workaround in your app getting the extended statistics and counting out some of extended counters from the ierrors. Here is an example: https://github.com/Juniper/contrail-vrouter/commit/72f6ca05ac81d0ca5e7eb93c6ffe7a93648c2b00#diff-99c1f65a00658c7d38b3d1b64cb5fd93R1306 Regards, Andriy On Wed, Oct 21, 2015 at 10:38 AM, Martin Weiser wrote: > Hi, > > with DPDK 2.1 we are seeing the ierrors counter increasing for 82599ES > ports without reason. Even directly after starting test-pmd the error > counter immediately is 1 without even a single packet being sent to the > device: > > ./testpmd -c 0xfe -n 4 -- --portmask 0x3 --interactive > ... > testpmd> show port stats all > > NIC statistics for port 0 > RX-packets: 0 RX-missed: 0 RX-bytes: 0 > RX-badcrc: 0 RX-badlen: 0 RX-errors: 1 > RX-nombuf: 0 > TX-packets: 0 TX-errors: 0 TX-bytes: 0 > > > NIC statistics for port 1 > RX-packets: 0 RX-missed: 0 RX-bytes: 0 > RX-badcrc: 0 RX-badlen: 0 RX-errors: 1 > RX-nombuf: 0 > TX-packets: 0 TX-errors: 0 TX-bytes: 0 > > > > When packet forwarding is started the ports perform normally and > properly forward all packets but a huge number of ierrors is counted: > > testpmd> start > ... > testpmd> show port stats all > > NIC statistics for port 0 > RX-packets: 9011857RX-missed: 0 RX-bytes: 5020932992 > RX-badcrc: 0 RX-badlen: 0 RX-errors: 9011753 > RX-nombuf: 0 > TX-packets: 9026250TX-errors: 0 TX-bytes: 2922375542 > > > NIC statistics for port 1 > RX-packets: 9026250RX-missed: 0 RX-bytes: 2922375542 > RX-badcrc: 0 RX-badlen: 0 RX-errors: 9026138 > RX-nombuf: 0 > TX-packets: 9011857TX-errors: 0 TX-bytes: 5020932992 > > > > When running the exact same test with DPDK version 2.0 no ierrors are > reported. > Is anyone else seeing strange ierrors being reported for Intel Niantic > cards with DPDK 2.1? > > Best regards, > Martin > -- Andriy Berestovskyy
[dpdk-dev] [PATCH] vhost-user: enable virtio 1.0
> b/lib/librte_vhost/virtio-net.c
>> > > index a51327d..ee4650e 100644
>> > > --- a/lib/librte_vhost/virtio-net.c
>> > > +++ b/lib/librte_vhost/virtio-net.c
>> > > @@ -75,6 +75,7 @@ static struct virtio_net_config_ll *ll_root;
>> > > (1ULL << VIRTIO_NET_F_CTRL_VQ) | \
>> > > (1ULL << VIRTIO_NET_F_CTRL_RX) | \
>> > > (1ULL << VIRTIO_NET_F_MQ) | \
>> > > + (1ULL << VIRTIO_F_VERSION_1) | \
>> > > (1ULL << VHOST_F_LOG_ALL) | \
>> > > (1ULL << VHOST_USER_F_PROTOCOL_FEATURES))
>> > > static uint64_t VHOST_FEATURES = VHOST_SUPPORTED_FEATURES;
>> > > @@ -477,17 +478,17 @@ set_features(struct vhost_device_ctx ctx, uint64_t
>> > > *pu)
>> > > return -1;
>> > >
>> > > dev->features = *pu;
>> > > - if (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) {
>> > > - LOG_DEBUG(VHOST_CONFIG,
>> > > - "(%"PRIu64") Mergeable RX buffers enabled\n",
>> > > - dev->device_fh);
>> > > + if (dev->features &
>> > > + ((1 << VIRTIO_NET_F_MRG_RXBUF) | (1ULL << VIRTIO_F_VERSION_1))) {
>> > > vhost_hlen = sizeof(struct virtio_net_hdr_mrg_rxbuf);
>> > > } else {
>> > > - LOG_DEBUG(VHOST_CONFIG,
>> > > - "(%"PRIu64") Mergeable RX buffers disabled\n",
>> > > - dev->device_fh);
>> > > vhost_hlen = sizeof(struct virtio_net_hdr);
>> > > }
>> > > + LOG_DEBUG(VHOST_CONFIG,
>> > > + "(%"PRIu64") Mergeable RX buffers %s, virtio 1 %s\n",
>> > > + dev->device_fh,
>> > > + (dev->features & (1 << VIRTIO_NET_F_MRG_RXBUF)) ? "on" :
>> > > "off",
>> > > + (dev->features & (1ULL << VIRTIO_F_VERSION_1)) ? "on" :
>> > > "off");
>> > >
>> > > for (i = 0; i < dev->virt_qp_nb; i++) {
>> > > uint16_t base_idx = i * VIRTIO_QNUM;
>> > > --
>> > > 2.1.0
--
Andriy Berestovskyy
[dpdk-dev] ixgbe: account more Rx errors Issue
Hi Maryam, Please see below. > XEC counts the Number of receive IPv4, TCP, UDP or SCTP XSUM errors Please note than UDP checksum is optional for IPv4, but UDP packets with zero checksum hit XEC. > And general crc errors counts Counts the number of receive packets with CRC > errors. Let me explain you with an example. DPDK 2.0 behavior: host A sends 10M IPv4 UDP packets (no checksum) to host B host B stats: 9M ipackets + 1M ierrors (missed) = 10M DPDK 2.1 behavior: host A sends 10M IPv4 UDP packets (no checksum) to host B host B stats: 9M ipackets + 11M in ierrors (1M missed + 10M XEC) = 20M? > So our options are we can: > 1. Add only one of these into the error stats. > 2. We can introduce some cooking of stats in this scenario, so only add > either or if they are equal or one is higher than the other. > 3. Add them all which means you can have more errors than the number of > received packets, but TBH this is going to be the case if your packets have > multiple errors anyway. 4. ierrors should reflect NIC drops only. XEC does not count drops, so IMO it should be removed from ierrors. Please note that we still can access the XEC using rte_eth_xstats_get() Regards, Andriy
[dpdk-dev] ixgbe: account more Rx errors Issue
Hi, Updating to DPDK 2.1 I noticed an issue with the ixgbe stats. In commit f6bf669b9900 "ixgbe: account more Rx errors" we add XEC hardware counter (l3_l4_xsum_error) to the ierrors now. The issue is the UDP packets with zero check sum are counted in XEC and now in ierrors too. I've tried to disable hw_ip_checksum in rxmode, but it didn't help. I'm not sure we should add XEC to ierrors, because packets counted in XEC are not dropped by the NIC actually. So in my case ierrors counter is now greater than actual number of packets received by the NIC, which makes no sense. What's your opinion? Regards, Andriy
[dpdk-dev] Non-working TX IP checksum offload
Cze?? Angela, Make sure your NIC is configured properly as described in this thread: http://dpdk.org/ml/archives/dev/2015-May/018096.html Andriy On Fri, Jul 17, 2015 at 4:23 PM, Angela Czubak wrote: > Hi, > > I have some difficulties using ip checksum tx offload capabilities - I > think I set everything as advised by the API documentation, but > unfortunately the packet leaves the interface with its ip checksum still > being zero (it reaches its destination). > > What I do is: > buffer->ol_flags |= PKT_TX_IP_CKSUM|PKT_TX_IPV4; > ip_header->hdr_checksum = 0; > buffer->l3_len = sizeof(struct ipv4_hdr); > buffer->l2_len = sizeof(struct ether_hdr); > > In L4 there's UDP, which checksum is zeroed if that matters. > > Is there something I am missing? The NIC is Intel Corporation Ethernet > Controller X710 for 10GbE SFP+ (rev 01). > > What is more, is there any particular reason for assuming in > i40e_xmit_pkts that offloading checksums is unlikely (I mean the line no > 1307 "if (unlikely(ol_flags & I40E_TX_CKSUM_OFFLOAD_MASK))" at > dpdk-2.0.0/lib/librte_pmd_i40e/i40e_rxtx.c)? > > Regards, > Angela -- Andriy Berestovskyy
[dpdk-dev] Free up completed TX buffers
Hi Zoltan, On Fri, May 29, 2015 at 7:00 PM, Zoltan Kiss wrote: > The easy way is just to increase your buffer pool's size to make > sure that doesn't happen. Go for it! > But there is no bulletproof way to calculate such > a number Yeah, there are many places for mbufs to stay :( I would try: Mempool size = sum(numbers of all TX descriptors) + sum(rx_free_thresh) + (mempool cache size * (number of lcores - 1)) + (burst size * number of lcores) > I'm thinking about a foolproof way, which is exposing functions like > ixgbe_tx_free_bufs from the PMDs, so the application can call it as a last > resort to avoid deadlock. Have a look at rte_eth_dev_tx_queue_stop()/start(). Some NICs (i.e. ixgbe) do reset the queue and free all the mbufs. Regards, Andriy
[dpdk-dev] Vhost user no connection vm2vm
guest? In my case on host I >> >> had 3.13.0 and on guests old 3.2 debian. >> >> >> >> >> >> >> >>> I just looked deeper into virtio back-end (vhost) but at first glace >> it >> >> seems like nothing coming from virtio. >> >> >> >> >> >> >> >>> What I'm going to do today is to compile newest kernel for vhost and >> >> guest and debug where packet flow stuck, I will report the result >> >> >> >> >> >> >> >>> On Thu, May 21, 2015 at 11:12 AM, Gaohaifeng (A) < >> >> gaohaifeng.gao at huawei.com> wrote: >> >> >> >>> Hi Maciej >> >> >Did you solve your problem? I meet this problem as your case. >> >> And I found avail_idx(in rte_vhost_dequeue_burst function) is always >> zero >> >> although I do send packets in VM. >> >> >> >>> Thanks. >> >> >> >> >> >>> Hello, I have strange issue with example/vhost app. >> >>> >> >>> I had compiled DPDK to run a vhost example app with followed flags >> >>> >> >>> CONFIG_RTE_LIBRTE_VHOST=y >> >>> CONFIG_RTE_LIBRTE_VHOST_USER=y >> >>> CONFIG_RTE_LIBRTE_VHOST_DEBUG=n >> >>> >> >>> then I run vhost app based on documentation: >> >>> >> >>> ./build/app/vhost-switch -c f -n 4 --huge-dir /mnt/huge --socket-mem >> >>> 3712 >> >>> -- -p 0x1 --dev-basename usvhost --vm2vm 1 --stats 9 >> >>> >> >>> -I use this strange --socket-mem 3712 because of physical limit of >> >>> memoryon device -with this vhost user I run two KVM machines with >> >>> followed parameters >> >>> >> >>> kvm -nographic -boot c -machine pc-i440fx-1.4,accel=kvm -name vm1 -cpu >> >>> host -smp 2 -hda /home/ubuntu/qemu/debian_squeeze2_amd64.qcow2 -m >> >>> 1024 -mem-path /mnt/huge -mem-prealloc -chardev >> >>> socket,id=char1,path=/home/ubuntu/dpdk/examples/vhost/usvhost >> >>> -netdev type=vhost-user,id=hostnet1,chardev=char1 >> >>> -device virtio-net >> >>> pci,netdev=hostnet1,id=net1,csum=off,gso=off,guest_tso4=off,guest_tso6 >> >>> = >> >>> off,guest_ecn=off >> >>> -chardev >> >>> socket,id=char2,path=/home/ubuntu/dpdk/examples/vhost/usvhost >> >>> -netdev type=vhost-user,id=hostnet2,chardev=char2 >> >>> -device >> >>> virtio-net- >> >>> pci,netdev=hostnet2,id=net2,csum=off,gso=off,guest_tso4=off,guest_tso6 >> >>> = >> >>> off,guest_ecn=off >> >>> >> >>> After running KVM virtio correctly starting (below logs from vhost app) >> >> ... >> >>> VHOST_CONFIG: mapped region 0 fd:31 to 0x2aaabae0 sz:0xa >> >>> off:0x0 >> >>> VHOST_CONFIG: mapped region 1 fd:37 to 0x2aaabb00 sz:0x1000 >> >>> off:0xc >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_NUM >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_BASE >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_ADDR >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK >> >>> VHOST_CONFIG: vring kick idx:0 file:38 >> >>> VHOST_CONFIG: virtio isn't ready for processing. >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_NUM >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_BASE >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_ADDR >> >>> VHOST_CONFIG: read message VHOST_USER_SET_VRING_KICK >> >>> VHOST_CONFIG: vring kick idx:1 file:39 >> >>> VHOST_CONFIG: virtio is now ready for processing. >> >>> VHOST_DATA: (1) Device has been added to data core 2 >> >>> >> >>> So everything looking good. >> >>> >> >>> Maybe it is something trivial but using options: --vm2vm 1 (or) 2 >> >>> --stats 9 it seems that I didn't have connection between VM2VM >> >>> communication. I set manually IP for eth0 and eth1: >> >>> >> >>> on 1 VM >> >>> ifconfig eth0 192.168.0.100 netmask 255.255.255.0 up ifconfig eth1 >> >>> 192.168.1.101 netmask 255.255.255.0 up >> >>> >> >>> on 2 VM >> >>> ifconfig eth0 192.168.1.200 netmask 255.255.255.0 up ifconfig eth1 >> >>> 192.168.0.202 netmask 255.255.255.0 up >> >>> >> >>> I notice that in vhostapp are one directional rx/tx queue so I tryied >> >>> to ping between VM1 to VM2 using both interfaces ping -I eth0 >> >>> 192.168.1.200 ping -I >> >>> eth1 192.168.1.200 ping -I eth0 192.168.0.202 ping -I eth1 >> >>> 192.168.0.202 >> >>> >> >>> on VM2 using tcpdump on both interfaces I didn't see any ICMP requests >> >>> or traffic >> >>> >> >>> And I cant ping between any IP/interfaces, moreover stats show me that: >> >>> >> >>> Device statistics >> >>> Statistics for device 0 -- >> >>> TX total: 0 >> >>> TX dropped: 0 >> >>> TX successful: 0 >> >>> RX total: 0 >> >>> RX dropped: 0 >> >>> RX successful: 0 >> >>> Statistics for device 1 -- >> >>> TX total: 0 >> >>> TX dropped: 0 >> >>> TX successful: 0 >> >>> RX total: 0 >> >>> RX dropped: 0 >> >>> RX successful: 0 >> >>> Statistics for device 2 -- >> >>> TX total: 0 >> >>> TX dropped: 0 >> >>> TX successful: 0 >> >>> RX total: 0 >> >>> RX dropped: 0 >> >>> RX successful: 0 >> >>> Statistics for device 3 -- >> >>> TX total: 0 >> >>> TX dropped: 0 >> >>> TX successful: 0 >> >>> RX total: 0 >> >>> RX dropped: 0 >> >>> RX successful: 0 >> >>> == >> >>> >> >>> So it seems like any packet didn't leave my VM. >> >>> also arp table is empty on each VM. >> >> >> >> >> >> -- Andriy Berestovskyy
[dpdk-dev] bond: mode 4 promiscuous mode
Hey guys,
Can we in function bond_mode_8023ad_activate_slave() try to add to the
slave bond and LACP multicast MACs first? And then we would fall back
into promiscuous mode if the adding has failed.
In other words:
if (rte_eth_dev_mac_addr_add(slave_id, bond_mac) != 0
|| rte_eth_dev_mac_addr_add(slave_id, lacp_mac) != 0) {
...
rte_eth_promiscuous_enable(slave_id)
}
Seems to work fine on my setup, but I might miss something.
Regards,
Andriy
