* [PATCH v8 6/6] testpmd: use Tx preparation in csum engine
From: Tomasz Kulasek @ 2016-10-21 14:46 UTC (permalink / raw)
To: dev; +Cc: konstantin.ananyev, olivier.matz
In-Reply-To: <1477061177-15828-1-git-send-email-tomaszx.kulasek@intel.com>
Removed pseudo header calculation for udp/tcp/tso packets from
application and used Tx preparation API for packet preparation and
verification.
Adding aditional step to the csum engine costs about 3-4% of performance
drop, on my setup with ixgbe driver. It's caused mostly by the need
of reaccessing and modification of packet data.
Signed-off-by: Tomasz Kulasek <tomaszx.kulasek@intel.com>
---
app/test-pmd/csumonly.c | 36 +++++++++++++-----------------------
1 file changed, 13 insertions(+), 23 deletions(-)
diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
index 57e6ae2..6f33ae9 100644
--- a/app/test-pmd/csumonly.c
+++ b/app/test-pmd/csumonly.c
@@ -112,15 +112,6 @@ struct simple_gre_hdr {
} __attribute__((__packed__));
static uint16_t
-get_psd_sum(void *l3_hdr, uint16_t ethertype, uint64_t ol_flags)
-{
- if (ethertype == _htons(ETHER_TYPE_IPv4))
- return rte_ipv4_phdr_cksum(l3_hdr, ol_flags);
- else /* assume ethertype == ETHER_TYPE_IPv6 */
- return rte_ipv6_phdr_cksum(l3_hdr, ol_flags);
-}
-
-static uint16_t
get_udptcp_checksum(void *l3_hdr, void *l4_hdr, uint16_t ethertype)
{
if (ethertype == _htons(ETHER_TYPE_IPv4))
@@ -370,32 +361,24 @@ process_inner_cksums(void *l3_hdr, const struct testpmd_offload_info *info,
/* do not recalculate udp cksum if it was 0 */
if (udp_hdr->dgram_cksum != 0) {
udp_hdr->dgram_cksum = 0;
- if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM) {
+ if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_UDP_CKSUM)
ol_flags |= PKT_TX_UDP_CKSUM;
- udp_hdr->dgram_cksum = get_psd_sum(l3_hdr,
- info->ethertype, ol_flags);
- } else {
+ else
udp_hdr->dgram_cksum =
get_udptcp_checksum(l3_hdr, udp_hdr,
info->ethertype);
- }
}
} else if (info->l4_proto == IPPROTO_TCP) {
tcp_hdr = (struct tcp_hdr *)((char *)l3_hdr + info->l3_len);
tcp_hdr->cksum = 0;
- if (tso_segsz) {
+ if (tso_segsz)
ol_flags |= PKT_TX_TCP_SEG;
- tcp_hdr->cksum = get_psd_sum(l3_hdr, info->ethertype,
- ol_flags);
- } else if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM) {
+ else if (testpmd_ol_flags & TESTPMD_TX_OFFLOAD_TCP_CKSUM)
ol_flags |= PKT_TX_TCP_CKSUM;
- tcp_hdr->cksum = get_psd_sum(l3_hdr, info->ethertype,
- ol_flags);
- } else {
+ else
tcp_hdr->cksum =
get_udptcp_checksum(l3_hdr, tcp_hdr,
info->ethertype);
- }
} else if (info->l4_proto == IPPROTO_SCTP) {
sctp_hdr = (struct sctp_hdr *)((char *)l3_hdr + info->l3_len);
sctp_hdr->cksum = 0;
@@ -648,6 +631,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
void *l3_hdr = NULL, *outer_l3_hdr = NULL; /* can be IPv4 or IPv6 */
uint16_t nb_rx;
uint16_t nb_tx;
+ uint16_t nb_prep;
uint16_t i;
uint64_t rx_ol_flags, tx_ol_flags;
uint16_t testpmd_ol_flags;
@@ -857,7 +841,13 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
printf("\n");
}
}
- nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, nb_rx);
+ nb_prep = rte_eth_tx_prep(fs->tx_port, fs->tx_queue, pkts_burst,
+ nb_rx);
+ if (nb_prep != nb_rx)
+ printf("Preparing packet burst to transmit failed: %s\n",
+ rte_strerror(rte_errno));
+
+ nb_tx = rte_eth_tx_burst(fs->tx_port, fs->tx_queue, pkts_burst, nb_prep);
/*
* Retry if necessary
*/
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 0/2] vhost: Add support to indirect descriptors on Rx path
From: Yuanhan Liu @ 2016-10-21 15:58 UTC (permalink / raw)
To: Maxime Coquelin; +Cc: dev, mst, zhihong.wang, ciara.loftus
In-Reply-To: <1476804939-8675-1-git-send-email-maxime.coquelin@redhat.com>
On Tue, Oct 18, 2016 at 05:35:37PM +0200, Maxime Coquelin wrote:
> Indirect descriptor feature has been enabled in v16.11-rc1, but only TX path
> was implemented.
> However, some configurations expect it is supported for the Rx path:
> - Windows guests with and without mergeable buffers enabled
> - Linux guests with Kernel drivr with mergeable buffers disabled
>
> This series add the support of indirect descs for the Rx path, and has been
> tested with following configurations:
> - Windows guest with indirect ON, mergeeable ON/OFF
> - Linux guest with Kernel driver with indirect ON/OFF, mergeable ON/OFF
> - Linux guest with Virtio PMD with mergeable ON/OFF
>
> The performance degradation measured with/without this series with Virtio PMD
> is around 1% (which doesn't use indirect descs for the Rx path).
>
> The series is based on top of "vhost: optimize mergeable Rx path" v7.
Series applied to dpdk-next-virtio.
Thanks.
--yliu
>
> Maxime Coquelin (2):
> vhost: Add indirect desc support to Rx mergeable path
> vhost: Add indirect desc support to the Rx no-mergeable path
>
> lib/librte_vhost/virtio_net.c | 73 ++++++++++++++++++++++++++++++-------------
> 1 file changed, 51 insertions(+), 22 deletions(-)
>
> --
> 2.7.4
^ permalink raw reply
* Re: Project Governance and Linux Foundation
From: Wiles, Keith @ 2016-10-21 17:20 UTC (permalink / raw)
To: Dave Neary; +Cc: O'Driscoll, Tim, dev@dpdk.org, users@dpdk.org
In-Reply-To: <580A1F94.9080304@redhat.com>
Thanks Dave for your work and notes: Comment inline
> On Oct 21, 2016, at 3:00 PM, Dave Neary <dneary@redhat.com> wrote:
>
> Hi all,
>
> We had a great session yesterday on this topic, I took some notes - does
> anyone who was there have any corrections, or anyone who was not have
> any comments?
>
> Thanks,
> Dave.
>
> Tim led the discussion, and started by outlining that he saw there were
> 3 different questions which we should treat independently:
>
> 1. Is there a benefit to moving DPDK to a foundation?
> 2. If the answer is yes: there are two options currently proposed - a
> low overhead, independent project under the Linux Foundation (LF Lite),
> or joining fd.io as a sub-project. Which one of these is preferable, or
> is there another option to consider?
> 3. Are there any related changes we should consider in technical
> infrastructure and project governance?
>
> I outlined some advantages I see to the Linux Foundation:
> * Pool resources for events
> * Provides some legal foresight
> * LF standing behind a project gives some companies assurances that
> there is good, open technical governance and a level playing field for
> participants
>
> Stephen Hemminger asked if there was a sponsorship requirement. Tim
> responded that it is possible to do what Open vSwitch has done, and have
> no membership funding requirement. What that means is that any funds the
> project community wants to spend needs to be budgeted ad hoc.
>
> A number of others (Shreyansh Jain, Matt Spencer) said they would like
> to see a formal model for non-technical engagement, legal protection for
> patent and copyright, and more clarity on the technical governance.
>
> Vincent Jardin said that whatever happens, it is vital that DPDK remain
> an open, community-run project.
>
> A number of people expressed interest in the change, but could not
> commit to funding.
>
> Jerome Tollet said that he felt it was important to have better test and
> CI infrastructure, and that these cost money. He proposed that since
> fd.io already has infrastructure and a lab, that this would be an
> affordable option for doing this.
>
> Vincent and Thomas Monjalon suggested that distributed testing was a
> better option - creating an opportunity for different people to send
> test results to a central gathering point. Thomas mentioned that
> Patchwork has a feature which allows aggregation of test results for
> specific patches now.
>
> Tim asked if there was agreement on a move, and there was no opposition.
> Vincent suggested opening a call for proposals to have a wider range of
> choices than LF Lite or fd.io. Jim St. Leger said we have already had a
> group who evaluated options and made a proposal, and we should not re-do
> the process.
>
> Jerome recommended that we focus on requirements and criteria for
> determining the choice: timing, governance requirements, budget, and
> hardware/infrastructure requirements. Keith Wiles suggested that there
> was a need for some budgetary requirement to show commitment of
> participating companies.
What I stated was more around, if we moved to LF we do need a budget and companies that want to contribute with money and/or people it would be great. I wanted to make sure everyone knows anyone can contribute for free to the project and the companies putting money in project are not controlling the technical part development of DPDK. At one point a year ago it was thought you had to pay to play/contribute to DPDK.
I also believe we do need a budget as the services LF provides are not free and we need to be able to support the project. If we can do something like OVS did with zero budget and still make it work then OK. The only problem I have is that model will not work, but I would like to be surprised.
>
> When asked about transferring the ownership of the domain name to Linux
> Foundation, Vincent reiterated that his main concern was keeping the
> project open, and that he did not anticipate that transferring the
> domain ownership would be an issue.
>
> Moving on to question 2:
>
> I said that Red Hat is happy with the technical operation of the
> project, and we don't want to see the community disrupted with toolset
> changes - and it's possible to work with projects like fd.io, OVS, and
> OPNFV to do testing of DPDK.
>
> Representatives from Brocade, Cavium, and Linaro all voiced a preference
> for a stand-alone lightweight project - one concern voiced was that
> there is a potential perception issue with fd.io too.
>
> Maciek K and Jerome encouraged everyone not to underestimate the
> difficulty in setting up good CI and testing processes.
>
> To close out the meeting, Tim summarised the consensus decisions:
>
> * We agreed to move to a foundation
> * A group will work on re-doing a budget proposal with the Linux
> Foundation - target of 4 weeks to come up with a budget proposal for the
> community
> * There is a preference for an independent project rather than being a
> sub-project
>
> Budget group:
> * Matt Spencer, ARM
> * Jerome Tollet, Cisco
> * Ed Warnicke, Cisco
> * Shreyansh Jain, NXP
> * Dave Neary, Red Hat
> * Jan Blunk, Brocade
> * Vincent Jardin, 6WIND
> * Thomas Monjalon, 6WIND
> * Tim O'Driscoll, Intel
> * Francois Ozog, Linaro
> * John Bromhead (sp?), Cavium
>
>
> On 10/10/2016 09:33 AM, O'Driscoll, Tim wrote:
>> This email is being sent on behalf of: Cavium, Cisco, Intel, NXP & Red Hat.
>>
>>
>> Since its creation as an open source project in 2013, DPDK has grown significantly. The number of DPDK users, contributors, commercial products that use DPDK and open source projects that depend on it have all increased consistently over that time. DPDK is now a key ingredient in networking and NFV, and we need to ensure that the project structure and governance are appropriate for such a critical project, and that they facilitate the project's continued growth.
>>
>> For over a year now we've been discussing moving DPDK to the Linux Foundation. We believe it's now time to conclude that discussion and make the move. The benefits of doing this would include:
>> - The infrastructure for a project like DPDK should not be owned and controlled by any single company.
>> - Remove any remaining perception that DPDK is not truly open.
>> - Allow the project to avail of the infrastructure and services provided by the Linux Foundation. These include things like: Ability to host infrastructure for integration and testing (the FD.io CSIT lab is an example of this - see https://wiki.fd.io/view/CSIT/CSIT_LF_testbed); Support for legal issues including trademarks and branding, and the ability to sign agreements on behalf of the project; Ability to pool resources for events and brand promotion; Safe haven for community IP resources.
>>
>> We don't propose to debate the details here. Instead, an open discussion session on DPDK Project Growth has been included in the agenda for the DPDK Summit Userspace 2016 event in Dublin. We propose using that session to agree that the DPDK project will move to the Linux Foundation, and then to move on to discussing the specifics. Things that we'll need to consider include:
>> - Whether DPDK moves to the Linux Foundation as an independent project or as part of a larger project like FD.io.
>> - Creation of a project charter similar to those created for FD.io (https://fd.io/governance/technical-community-charter) and Open vSwitch (see http://openvswitch.org/pipermail/discuss/attachments/20160619/5a2df53e/attachment-0001.pdf).
>> - Agreement on budget, membership levels etc. A draft budget was created by the LF during previous discussions (https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256), but it is possible to adopt an even more lightweight model.
>>
>> We could look at alternatives to the Linux Foundation, but a) we've been talking to the LF for over a year now, and b) the preponderance of networking projects in LF, like ODL, FD.io, and OVS, makes it a natural destination for DPDK.
>>
>> As highlighted in previous discussions on this topic, it's important to stress that the intent is not to make significant changes to the technical governance and decision making of the project. The project has a strong set of maintainers and a Technical Board in place already. What's required is to supplement that with an open governance structure taking advantage of the services offered by the Linux Foundation.
>>
>> The purpose of this email is to outline what we want to achieve during that discussion session in Dublin, and to allow people to consider the issue and prepare in advance. If people want to comment via email on the mailing list, that's obviously fine, but we believe that an open and frank discussion when people meet in person in Dublin is the best way to progress this.
>>
>>
>> For reference, below is a brief history of the previous discussions on this topic:
>>
>> September 2015:
>> - A DPDK community call was held to discuss project growth and possible improvements. This was the first public discussion on possible governance changes. The agreed next step was to discuss this in more detail at the 2015 DPDK Summit Userspace event Dublin. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2015-September/024120.html.
>>
>> October 2015:
>> - An open discussion session on project governance was held at the 2015 DPDK Summit Userspace event. For technical governance, we agreed to investigate creating a technical steering committee. For non-technical governance (including things like event planning, legal and trademark issues, hosting of the website etc.), we agreed to work with the Linux Foundation on a proposal for a lightweight governance model for DPDK. Minutes of the discussion are at: http://dpdk.org/ml/archives/dev/2015-October/024825.html.
>>
>> - The proposal for a technical steering committee was subsequently discussed on the mailing list (http://dpdk.org/ml/archives/dev/2015-October/026598.html) and agreed, leading to the creation of the DPDK Technical Board (http://dpdk.org/dev#board).
>>
>> December 2015:
>> - A community call was held to discuss migration to the Linux Foundation. Mike Dolan (VP of Strategic Programs at The Linux Foundation) gave an overview of the LF and the services they can provide. We agreed to form a small sub-team (Dave Neary, Thomas Monjalon, Stephen Hemminger, Tim O'Driscoll) to work with the LF on a more detailed proposal. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2015-December/030532.html.
>>
>> February 2016:
>> - A community call was held to discuss the LF budget proposal (see https://docs.google.com/spreadsheets/d/1-3686Xb_jf4FtxdX8Mus9UwIxUb2vI_ppmJV5GnXcLg/edit#gid=302618256). We agreed to discuss this further on the dev mailing list due to limited attendance on the call. Minutes of the call are at: http://dpdk.org/ml/archives/dev/2016-February/032720.html.
>>
>> - A request was made on the dev and announce mailing lists too determine who supported the proposal to move to the Linux Foundation (http://dpdk.org/ml/archives/dev/2016-February/033192.html). There was public support from Intel (http://dpdk.org/ml/archives/dev/2016-February/033297.html) and Brocade (http://dpdk.org/ml/archives/dev/2016-February/033359.html). 6WIND requested postponing the move for a few months (http://dpdk.org/ml/archives/dev/2016-February/033299.html).
>>
>> - The Fast Data (FD.io) project was established under the Linux Foundation (https://fd.io/news/announcement/2016/02/linux-foundation-forms-open-source-effort-advance-io-services).
>>
>> June 2016:
>> - The Open vSwitch project proposed moving to the Linux Foundation (http://openvswitch.org/pipermail/discuss/2016-June/021761.html).
>>
>> August 2016:
>> - The Open vSwitch project moved to the Linux Foundation (https://www.linuxfoundation.org/announcements/open-vswitch-joins-linux-foundation-open-networking-ecosystem).
>>
>
> --
> Dave Neary - NFV/SDN Community Strategy
> Open Source and Standards, Red Hat - http://community.redhat.com
> Ph: +1-978-399-2182 / Cell: +1-978-799-3338
Regards,
Keith
^ permalink raw reply
* Re: [PATCH 1/2] drivers: add name alias registration for rte_driver
From: De Lara Guarch, Pablo @ 2016-10-21 18:31 UTC (permalink / raw)
To: Jan Blunck, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, yuanhan.liu@linux.intel.com,
Mcnamara, John
In-Reply-To: <1476956223-30308-1-git-send-email-jblunck@infradead.org>
> -----Original Message-----
> From: Jan Blunck [mailto:jblunck@gmail.com] On Behalf Of Jan Blunck
> Sent: Thursday, October 20, 2016 2:37 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo; thomas.monjalon@6wind.com;
> yuanhan.liu@linux.intel.com; Mcnamara, John
> Subject: [PATCH 1/2] drivers: add name alias registration for rte_driver
>
> This adds infrastructure for drivers to allow being requested by an alias
> so that a renamed driver can still get loaded by its legacy name.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
Hi Jan,
I saw two checkpatch errors in this patch that should be fixed:
ERROR: "foo * bar" should be "foo *bar"
#55: FILE: lib/librte_eal/common/include/rte_vdev.h:86:
+static const char * vdrvinit_ ## nm ## _alias;\
ERROR: "foo * bar" should be "foo *bar"
#65: FILE: lib/librte_eal/common/include/rte_vdev.h:96:
+static const char * vdrvinit_ ## nm ## _alias = RTE_STR(alias)
total: 2 errors, 0 warnings, 39 lines checked
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH 2/2] drivers: register aliases for renamed VDEV drivers
From: De Lara Guarch, Pablo @ 2016-10-21 18:33 UTC (permalink / raw)
To: Jan Blunck, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, yuanhan.liu@linux.intel.com,
Mcnamara, John
In-Reply-To: <1476956223-30308-2-git-send-email-jblunck@infradead.org>
> -----Original Message-----
> From: Jan Blunck [mailto:jblunck@gmail.com] On Behalf Of Jan Blunck
> Sent: Thursday, October 20, 2016 2:37 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo; thomas.monjalon@6wind.com;
> yuanhan.liu@linux.intel.com; Mcnamara, John
> Subject: [PATCH 2/2] drivers: register aliases for renamed VDEV drivers
>
> This registers the legacy names of the driver being renamed in commit
> 2f45703c17acb943aaded9f79676fd56a72542b2.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
Hi Jan,
Please, follow the convention to refer to other commits.
>From checkpatch:
ERROR: Please use git commit description style 'commit <12+ chars of sha1>
("<title line>")' - ie: 'commit 2f45703c17ac ("drivers: make driver names consistent")'
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH] drivers: register aliases for renamed cryptodev drivers
From: De Lara Guarch, Pablo @ 2016-10-21 18:35 UTC (permalink / raw)
To: Jan Blunck, dev@dpdk.org
Cc: thomas.monjalon@6wind.com, yuanhan.liu@linux.intel.com,
Mcnamara, John
In-Reply-To: <1477048976-18561-1-git-send-email-jblunck@infradead.org>
> -----Original Message-----
> From: Jan Blunck [mailto:jblunck@gmail.com] On Behalf Of Jan Blunck
> Sent: Friday, October 21, 2016 4:23 AM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo; thomas.monjalon@6wind.com;
> yuanhan.liu@linux.intel.com; Mcnamara, John
> Subject: [PATCH] drivers: register aliases for renamed cryptodev drivers
>
> This registers the legacy names of the driver being renamed in commit
> 2f45703c17acb943aaded9f79676fd56a72542b2.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
> drivers/crypto/aesni_gcm/aesni_gcm_pmd.c | 1 +
> drivers/crypto/aesni_mb/rte_aesni_mb_pmd.c | 1 +
> drivers/crypto/kasumi/rte_kasumi_pmd.c | 1 +
> drivers/crypto/null/null_crypto_pmd.c | 1 +
> drivers/crypto/snow3g/rte_snow3g_pmd.c | 1 +
> 5 files changed, 5 insertions(+)
Hi Jan,
Please, follow the convention to refer to other commits.
>From checkpatch:
ERROR: Please use git commit description style 'commit <12+ chars of sha1>
("<title line>")' - ie: 'commit 2f45703c17ac ("drivers: make driver names consistent")'
Also, this can probably be merged to the other patch that adds the aliases
for the network drivers, or maybe include it in the same patchset.
I have also tested this, and it works, so you can add:
Tested-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
Thanks for the work!
Pablo
^ permalink raw reply
* Manual link speed/duplex configuration not working with DPDK
From: Ananda Sathyanarayana @ 2016-10-21 19:27 UTC (permalink / raw)
To: dev; +Cc: ananda, Vignesh Chinnakkannu
Hi All,
While testing manual link speed/duplex configuration with DPDK 1.7.1, I
observed the same issues mentioned by the below post
http://dpdk.org/ml/archives/dev/2015-January/010834.html. I see the same
issue with 16.04 as well.
Looks like the above patch is not accepted by the DPDK community yet. Any
specific reason ?
>From the code, it looks like, hw->mac.autoneg, variable is used to switch
between calling either autoneg function or forcing speed/duplex function.
But this variable is not modified in eth_em_start/eth_igb_start routines
(it is always set to 1) while forcing the link.
s32 e1000_setup_copper_link_generic(struct e1000_hw *hw)
{
s32 ret_val;
bool link;
DEBUGFUNC("e1000_setup_copper_link_generic");
if (hw->mac.autoneg) { <<<<<<<<<<<< always set, is not modified
in eth_em_start/eth_igb_start
/* Setup autoneg and flow control advertisement and perform
* autonegotiation.
*/
ret_val = e1000_copper_link_autoneg(hw);
if (ret_val)
return ret_val;
} else {
/* PHY will be set to 10H, 10F, 100H or 100F
* depending on user settings.
*/
DEBUGOUT("Forcing Speed and Duplex\n");
ret_val = hw->phy.ops.force_speed_duplex(hw);
<<<<<<<<<<<< Not called at all
if (ret_val) {
DEBUGOUT("Error Forcing Speed and Duplex\n");
return ret_val;
}
}
}
Thanks,
Ananda
^ permalink raw reply
* Re: Manual link speed/duplex configuration not working with DPDK
From: Anupam Kapoor @ 2016-10-22 2:26 UTC (permalink / raw)
To: Ananda Sathyanarayana; +Cc: dev, Vignesh Chinnakkannu
In-Reply-To: <68694134d146c7848435452dad3446d9@mail.gmail.com>
On Sat, Oct 22, 2016 at 12:57 AM, Ananda Sathyanarayana <
ananda@versa-networks.com> wrote:
> Looks like the above patch is not accepted by the DPDK community yet. Any
> specific reason ?
>
primary reason seems to be because the patch was not in correct format and
e1000 had no maintainer identified. since the latter is now there, the
former can be resent ?
--
thanks
anupam
--
In the beginning was the lambda, and the lambda was with Emacs, and Emacs
was the lambda.
^ permalink raw reply
* Re: [PATCH 1/2] drivers: add name alias registration for rte_driver
From: Maxime Coquelin @ 2016-10-22 11:24 UTC (permalink / raw)
To: Jan Blunck, dev
Cc: pablo.de.lara.guarch, thomas.monjalon, yuanhan.liu, john.mcnamara
In-Reply-To: <1476956223-30308-1-git-send-email-jblunck@infradead.org>
On 10/20/2016 11:37 AM, Jan Blunck wrote:
> This adds infrastructure for drivers to allow being requested by an alias
> so that a renamed driver can still get loaded by its legacy name.
>
> Signed-off-by: Jan Blunck <jblunck@infradead.org>
> ---
> lib/librte_eal/common/eal_common_vdev.c | 8 ++++++++
> lib/librte_eal/common/include/rte_dev.h | 1 +
> lib/librte_eal/common/include/rte_vdev.h | 5 +++++
> 3 files changed, 14 insertions(+)
Hi Jan,
This looks good to me, once Pablo's comment is taken into account, feel
free to add my:
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Thanks for doing the work!
Maxime
^ permalink raw reply
* Re: Project Governance and Linux Foundation
From: Thomas Monjalon @ 2016-10-22 19:27 UTC (permalink / raw)
To: moving; +Cc: dev, users
In-Reply-To: <580A1F94.9080304@redhat.com>
Hi,
Thanks Dave for the report.
I suggest to continue on the new mailing list:
moving@dpdk.org
Please register if you are interested in the structure move:
http://dpdk.org/ml/listinfo/moving
2016-10-21 15:00, Dave Neary:
> Hi all,
>
> We had a great session yesterday on this topic, I took some notes - does
> anyone who was there have any corrections, or anyone who was not have
> any comments?
>
> Thanks,
> Dave.
>
> Tim led the discussion, and started by outlining that he saw there were
> 3 different questions which we should treat independently:
>
> 1. Is there a benefit to moving DPDK to a foundation?
> 2. If the answer is yes: there are two options currently proposed - a
> low overhead, independent project under the Linux Foundation (LF Lite),
> or joining fd.io as a sub-project. Which one of these is preferable, or
> is there another option to consider?
> 3. Are there any related changes we should consider in technical
> infrastructure and project governance?
>
> I outlined some advantages I see to the Linux Foundation:
> * Pool resources for events
> * Provides some legal foresight
> * LF standing behind a project gives some companies assurances that
> there is good, open technical governance and a level playing field for
> participants
>
> Stephen Hemminger asked if there was a sponsorship requirement. Tim
> responded that it is possible to do what Open vSwitch has done, and have
> no membership funding requirement. What that means is that any funds the
> project community wants to spend needs to be budgeted ad hoc.
>
> A number of others (Shreyansh Jain, Matt Spencer) said they would like
> to see a formal model for non-technical engagement, legal protection for
> patent and copyright, and more clarity on the technical governance.
>
> Vincent Jardin said that whatever happens, it is vital that DPDK remain
> an open, community-run project.
>
> A number of people expressed interest in the change, but could not
> commit to funding.
>
> Jerome Tollet said that he felt it was important to have better test and
> CI infrastructure, and that these cost money. He proposed that since
> fd.io already has infrastructure and a lab, that this would be an
> affordable option for doing this.
>
> Vincent and Thomas Monjalon suggested that distributed testing was a
> better option - creating an opportunity for different people to send
> test results to a central gathering point. Thomas mentioned that
> Patchwork has a feature which allows aggregation of test results for
> specific patches now.
>
> Tim asked if there was agreement on a move, and there was no opposition.
> Vincent suggested opening a call for proposals to have a wider range of
> choices than LF Lite or fd.io. Jim St. Leger said we have already had a
> group who evaluated options and made a proposal, and we should not re-do
> the process.
>
> Jerome recommended that we focus on requirements and criteria for
> determining the choice: timing, governance requirements, budget, and
> hardware/infrastructure requirements. Keith Wiles suggested that there
> was a need for some budgetary requirement to show commitment of
> participating companies.
>
> When asked about transferring the ownership of the domain name to Linux
> Foundation, Vincent reiterated that his main concern was keeping the
> project open, and that he did not anticipate that transferring the
> domain ownership would be an issue.
>
> Moving on to question 2:
>
> I said that Red Hat is happy with the technical operation of the
> project, and we don't want to see the community disrupted with toolset
> changes - and it's possible to work with projects like fd.io, OVS, and
> OPNFV to do testing of DPDK.
>
> Representatives from Brocade, Cavium, and Linaro all voiced a preference
> for a stand-alone lightweight project - one concern voiced was that
> there is a potential perception issue with fd.io too.
>
> Maciek K and Jerome encouraged everyone not to underestimate the
> difficulty in setting up good CI and testing processes.
>
> To close out the meeting, Tim summarised the consensus decisions:
>
> * We agreed to move to a foundation
> * A group will work on re-doing a budget proposal with the Linux
> Foundation - target of 4 weeks to come up with a budget proposal for the
> community
> * There is a preference for an independent project rather than being a
> sub-project
>
> Budget group:
> * Matt Spencer, ARM
> * Jerome Tollet, Cisco
> * Ed Warnicke, Cisco
> * Shreyansh Jain, NXP
> * Dave Neary, Red Hat
> * Jan Blunk, Brocade
> * Vincent Jardin, 6WIND
> * Thomas Monjalon, 6WIND
> * Tim O'Driscoll, Intel
> * Francois Ozog, Linaro
> * John Bromhead (sp?), Cavium
^ permalink raw reply
* rte_kni_tx_burst() hangs because of no free descriptors
From: =?gb18030?B?eWluZ3poaQ==?= @ 2016-10-23 13:29 UTC (permalink / raw)
To: =?gb18030?B?dXNlcnM=?=, =?gb18030?B?ZGV2QGRwZGsub3Jn?=
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 2513 bytes --]
¡ª
Hi Experts,
Background:
We are using DPDK to develop a LoadBalancer following below logic: When a new packet is received:
1. if the dst_addr is management IP, forward to KNI. 2. if the dst_addr is in VIP list, select backend and forward(modify dst mac address). 3. otherwise drop the packet.
At this stage, we use one single thread for KNI forwarding and another for VIP forwarding(forward to eth).
DPDK version: 16.07
NIC: 82599ES 10-Gigabit SFI/SFP+ Network Connection
Linux: 14.04.1-Ubuntu x64
Promblem description:
The program runs correctly for sometime(around 2 hours for 400Mb traffic). But it it will hang. When problem happens, rte_eth_tx_burst() will not able to send out any packets(always returns 0). We tracked into that function and noticed it is actually calling ixgbe driver's ixgbe_xmit_pkts_vec() function in our environment, because we use default tx queue configuration, after printing some info, we found if the free function works fine:
tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 31
it will trigger free and make 32 more free descriptors:
tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 62
but when something going wrong, it will no longer free anything:
tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 0 tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 0
It may related with the DD flag of the descriptor but we are not quite sure.
Our program logic:
create two mbuf pools on socket 0, one for rx_queue and one for kni. (all lcore threads runs on socket0)
init kni interface with rte_kni_alloc()
init one NIC interface with
rte_eth_dev_configure(); rte_eth_rx_queue_setup(); rte_eth_tx_queue_setup(); rte_eth_dev_start();
in the eth main loop: (code is simplified)
while(1) { n = rte_eth_rx_burst(packets); for (i = 0; i < n; ++i) { if (SEND_TO_KNI) { m = rte_kni_tx_burst(packets[i]); if (m != 1)) { rte_pktmbuf_free(packets[i]); } } if (SEND_TO_ETH) { // after modify the packet m = rte_eth_tx_burst(packets[i]); if (m != 1)) { rte_pktmbuf_free(packets[i]); } } // otherwise drop the packet rte_pktmbuf_free(packets[i]); } }
Please advise if I'm using DPDK in a wrong way. Sorry if I missed something basic, I'm new to DPDK.
Thanks in advance
Best regards
^ permalink raw reply
* Re: Manual link speed/duplex configuration not working with DPDK
From: Lu, Wenzhuo @ 2016-10-24 0:54 UTC (permalink / raw)
To: Ananda Sathyanarayana, dev@dpdk.org; +Cc: Vignesh Chinnakkannu
In-Reply-To: <68694134d146c7848435452dad3446d9@mail.gmail.com>
Hi Ananda,
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananda
> Sathyanarayana
> Sent: Saturday, October 22, 2016 3:27 AM
> To: dev@dpdk.org
> Cc: ananda@versa-networks.com; Vignesh Chinnakkannu
> Subject: [dpdk-dev] Manual link speed/duplex configuration not working with
> DPDK
>
> Hi All,
>
>
>
> While testing manual link speed/duplex configuration with DPDK 1.7.1, I
> observed the same issues mentioned by the below post
>
> http://dpdk.org/ml/archives/dev/2015-January/010834.html. I see the same
> issue with 16.04 as well.
Don’t know the history. Seems it’s discussion but not a patch. Guess that's why it’s not accepted.
It looks OK to me. Maybe we can create a patch for it?
>
>
>
> Looks like the above patch is not accepted by the DPDK community yet. Any
> specific reason ?
>
>
>
> From the code, it looks like, hw->mac.autoneg, variable is used to switch
> between calling either autoneg function or forcing speed/duplex function.
> But this variable is not modified in eth_em_start/eth_igb_start routines (it is
> always set to 1) while forcing the link.
>
>
>
> s32 e1000_setup_copper_link_generic(struct e1000_hw *hw)
>
> {
>
> s32 ret_val;
>
> bool link;
>
>
>
> DEBUGFUNC("e1000_setup_copper_link_generic");
>
>
>
> if (hw->mac.autoneg) { <<<<<<<<<<<< always set, is not modified
> in eth_em_start/eth_igb_start
>
>
>
> /* Setup autoneg and flow control advertisement and perform
>
> * autonegotiation.
>
> */
>
> ret_val = e1000_copper_link_autoneg(hw);
>
> if (ret_val)
>
> return ret_val;
>
> } else {
>
> /* PHY will be set to 10H, 10F, 100H or 100F
>
> * depending on user settings.
>
> */
>
> DEBUGOUT("Forcing Speed and Duplex\n");
>
> ret_val = hw->phy.ops.force_speed_duplex(hw);
> <<<<<<<<<<<< Not called at all
>
> if (ret_val) {
>
> DEBUGOUT("Error Forcing Speed and Duplex\n");
>
> return ret_val;
>
> }
>
> }
>
>
>
> }
>
>
>
>
>
> Thanks,
>
> Ananda
^ permalink raw reply
* Re: [PATCH 1/2] net/i40e: fix link status change interrupt
From: Yang, Qiming @ 2016-10-24 2:21 UTC (permalink / raw)
To: Yigit, Ferruh, dev@dpdk.org; +Cc: Wu, Jingjing, Zhang, Helin
In-Reply-To: <2eed66c7-14df-9950-bd92-cecafc8267f0@intel.com>
Ferruh,
Thank you for your reminder, I will remember to CC to the maintainer in future.
Jingjing and Helin,
Can you help to review these two patches?
Thanks,
Qiming
-----Original Message-----
From: Yigit, Ferruh
Sent: Wednesday, October 19, 2016 6:57 PM
To: Yang, Qiming <qiming.yang@intel.com>; dev@dpdk.org
Cc: Wu, Jingjing <jingjing.wu@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/2] net/i40e: fix link status change interrupt
Hi Qiming,
On 10/13/2016 7:07 AM, Qiming Yang wrote:
> Previously, link status interrupt in i40e is achieved by checking
> LINK_STAT_CHANGE_MASK in PFINT_ICR0 register which is provided only
> for diagnostic use. Instead, drivers need to get the link status
> change notification by using LSE (Link Status Event).
>
> This patch enables LSE and calls LSC callback when the event is
> received. This patch also removes the processing on
> LINK_STAT_CHANGE_MASK.
>
> Fixes: 5c9222058df7 ("i40e: move to drivers/net/")
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
CC: Jingjing Wu <jingjing.wu@intel.com>
Can you please add maintainer(s) to CC when sending a patch, mail traffic in dpdk.org is keep increasing and it is hard to follow. Adding maintainer to the CC helps a lot to the maintainer.
I guess everybody knows, but just as a reminder, maintainer list kept in
file: http://dpdk.org/browse/dpdk/tree/MAINTAINERS
Thanks,
ferruh
^ permalink raw reply
* Re: rte_kni_tx_burst() hangs because of no free descriptors
From: Zhang, Helin @ 2016-10-24 3:33 UTC (permalink / raw)
To: yingzhi; +Cc: dev@dpdk.org
In-Reply-To: <tencent_7A3B21E976B640D577D77530@qq.com>
Hi Yingzhi
Thank you for the reporting! The description is not so clear at least for me.
Please help to narrown down the issue by youself.
How many packets would it have for calling TX function?
Why it would return 0 after calling TX function? No memory? Or return from else? Have you found anything?
Regards,
Helin
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of yingzhi
> Sent: Sunday, October 23, 2016 9:30 PM
> To: users; dev@dpdk.org
> Subject: [dpdk-dev] rte_kni_tx_burst() hangs because of no free descriptors
>
> -
> Hi Experts,
>
> Background:
>
> We are using DPDK to develop a LoadBalancer following below logic: When
> a new packet is received:
> 1. if the dst_addr is management IP, forward to KNI. 2. if the dst_addr is in
> VIP list, select backend and forward(modify dst mac address). 3. otherwise
> drop the packet.
>
> At this stage, we use one single thread for KNI forwarding and another for
> VIP forwarding(forward to eth).
>
> DPDK version: 16.07
> NIC: 82599ES 10-Gigabit SFI/SFP+ Network Connection
> Linux: 14.04.1-Ubuntu x64
>
> Promblem description:
>
> The program runs correctly for sometime(around 2 hours for 400Mb traffic).
> But it it will hang. When problem happens, rte_eth_tx_burst() will not able to
> send out any packets(always returns 0). We tracked into that function and
> noticed it is actually calling ixgbe driver's ixgbe_xmit_pkts_vec() function in
> our environment, because we use default tx queue configuration, after
> printing some info, we found if the free function works fine:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 31
>
> it will trigger free and make 32 more free descriptors:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 62
>
> but when something going wrong, it will no longer free anything:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 0 tx_rs_thresh: 32,
> tx_free_thresh: 32, nb_tx_free: 0
>
> It may related with the DD flag of the descriptor but we are not quite sure.
>
> Our program logic:
>
> create two mbuf pools on socket 0, one for rx_queue and one for kni. (all
> lcore threads runs on socket0)
>
> init kni interface with rte_kni_alloc()
>
>
> init one NIC interface with
> rte_eth_dev_configure(); rte_eth_rx_queue_setup();
> rte_eth_tx_queue_setup(); rte_eth_dev_start();
>
>
>
> in the eth main loop: (code is simplified)
> while(1) { n = rte_eth_rx_burst(packets); for (i = 0; i < n; ++i) { if
> (SEND_TO_KNI) { m = rte_kni_tx_burst(packets[i]); if (m != 1))
> { rte_pktmbuf_free(packets[i]); } } if (SEND_TO_ETH)
> { // after modify the packet m = rte_eth_tx_burst(packets[i]);
> if (m != 1)) { rte_pktmbuf_free(packets[i]); } } //
> otherwise drop the packet rte_pktmbuf_free(packets[i]); } }
>
>
> Please advise if I'm using DPDK in a wrong way. Sorry if I missed something
> basic, I'm new to DPDK.
>
> Thanks in advance
> Best regards
^ permalink raw reply
* Re: [PATCH 1/2] examples/tep_term: Fix l4_len issue
From: Tan, Jianfeng @ 2016-10-24 5:41 UTC (permalink / raw)
To: Michael Qiu, dev@dpdk.org; +Cc: Michael Qiu
In-Reply-To: <1476769747-23289-1-git-send-email-qiudayu@chinac.com>
> -----Original Message-----
> From: Michael Qiu [mailto:qdy220091330@gmail.com]
> Sent: Tuesday, October 18, 2016 1:49 PM
> To: dev@dpdk.org
> Cc: Tan, Jianfeng; Michael Qiu
> Subject: [PATCH 1/2] examples/tep_term: Fix l4_len issue
>
> l4_len is not fixed, althrough mostly it is a fixed value,
> but when guest using iperf to do some tests, the l4_len
> will have another 12 bytes optional fields.
>
> Fixes: 2bb43bd4350a("examples/tep_term: add TSO offload configuration")
>
> Signed-off-by: Michael Qiu <qiudayu@chinac.com>
Acked-by: Jianfeng Tan <jianfeng.tan@intel.com>
Thanks,
Jianfeng
^ permalink raw reply
* Re: [PATCH 2/2] examples/tep_term: Fix packet len for multi-seg mbuf
From: Tan, Jianfeng @ 2016-10-24 5:41 UTC (permalink / raw)
To: Michael Qiu, dev@dpdk.org; +Cc: Michael Qiu
In-Reply-To: <1476769747-23289-2-git-send-email-qiudayu@chinac.com>
> -----Original Message-----
> From: Michael Qiu [mailto:qdy220091330@gmail.com]
> Sent: Tuesday, October 18, 2016 1:49 PM
> To: dev@dpdk.org
> Cc: Tan, Jianfeng; Michael Qiu
> Subject: [PATCH 2/2] examples/tep_term: Fix packet len for multi-seg mbuf
>
> For multi-seg mbuf, ip->total_length should be pkt_len subtract
> ether len.
>
> Fixes: 4abe471ed6fc("examples/tep_term: implement VXLAN processing")
>
> Signed-off-by: Michael Qiu <qiudayu@chinac.com>
Acked-by: Jianfeng Tan <jianfeng.tan@intel.com>
Thanks,
Jianfeng
^ permalink raw reply
* DPDK-QoS- Using un-used bandwidth within a class
From: sreenaath vasudevan @ 2016-10-24 7:04 UTC (permalink / raw)
To: dev, Dumitrescu, Cristian
Hi
I am using DPDK QoS and I find something strange. I am not sure if
something is wrong with my config or my understanding of queue weights is
wrong.
In my config, I am using only 1 port and 1 subport and 1 pipe. Within that
pipe, I am using only the last class (C3). Port, subport and pipe are
configured with 100Mbps speed.
C3 is given the entire pipe's TB rate i.e entire bandwidth in essence.
In C3, I am giving relative weights of 1:4:2:2 for the four queues
q0,q1,q2,q3
When no other traffic is coming in to q0,q2,q3, I am pumping ~100Mbps in to
q1. However, I am seeing only 40% of the traffic going through q1. In other
words the max throughput allowed through the queue is based on its weight
and the unused bandwidth is not used.
Cannot the unused bandwidth from q0,q2 and q3 be used for q1?
Note-
Following is the QoS config output spit out by DPDK in syslog
SCHED: Low level config for pipe profile 0:
token bucket: period = 10, credits per period = 1, size = 25000
Traffic classes: period = 1250000, credits per period = [0, 0, 0, 125000]
Traffic class 3 oversubscription: weight = 0
WRR cost: [1, 1, 1, 1], [1, 1, 1, 1], [1, 1, 1, 1], [4, 1, 2, 2]
SCHED: Low level config for subport 0:
Token bucket: period = 10, credits per period = 1, size = 25000
Traffic classes: period = 1250000, credits per period = [0, 0, 0, 125000]
Traffic class 3 oversubscription: wm min = 0, wm max = 0
--
regards
sreenaath
^ permalink raw reply
* [PATCH] net/mlx5: fix default set for multicast traffic
From: Raslan Darawsheh @ 2016-10-24 7:59 UTC (permalink / raw)
To: dev; +Cc: Raslan Darawsheh, Adrien Mazarguil
Remove non-IPv6 multicast traffic with destination MAC 33:33:* from the
default set when not in promiscuous or allmulticast modes.
Fixes: 0497ddaac511 ("mlx5: add special flows for broadcast and IPv6 multicast")
Signed-off-by: Raslan Darawsheh <rasland@mellanox.com>
---
drivers/net/mlx5/mlx5_rxmode.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_rxmode.c b/drivers/net/mlx5/mlx5_rxmode.c
index 173e6e8..4ffe703 100644
--- a/drivers/net/mlx5/mlx5_rxmode.c
+++ b/drivers/net/mlx5/mlx5_rxmode.c
@@ -104,7 +104,6 @@ static const struct special_flow_init special_flow_init[] = {
.hash_types =
1 << HASH_RXQ_UDPV6 |
1 << HASH_RXQ_IPV6 |
- 1 << HASH_RXQ_ETH |
0,
.per_vlan = 1,
},
--
1.9.1
^ permalink raw reply related
* [PATCH] net/mlx5: fix handling of small mbuf sizes
From: Raslan Darawsheh @ 2016-10-24 8:10 UTC (permalink / raw)
To: dev; +Cc: Raslan Darawsheh, Adrien Mazarguil
When mbufs are smaller than MRU, multi-segment support must be enabled to
default set when not in promiscuous or allmulticast modes.
Fixes: 9964b965ad69 ("net/mlx5: re-add Rx scatter support")
Signed-off-by: Raslan Darawsheh <rasland@mellanox.com>
---
drivers/net/mlx5/mlx5_rxq.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
index 4dc5cc3..62253ed 100644
--- a/drivers/net/mlx5/mlx5_rxq.c
+++ b/drivers/net/mlx5/mlx5_rxq.c
@@ -946,6 +946,12 @@ rxq_ctrl_setup(struct rte_eth_dev *dev, struct rxq_ctrl *rxq_ctrl,
(void)conf; /* Thresholds configuration (ignored). */
/* Enable scattered packets support for this queue if necessary. */
assert(mb_len >= RTE_PKTMBUF_HEADROOM);
+ /* If smaller than MRU, multi-segment support must be enabled. */
+ if (mb_len < (priv->mtu > dev->data->dev_conf.rxmode.max_rx_pkt_len ?
+ dev->data->dev_conf.rxmode.max_rx_pkt_len :
+ priv->mtu
+ ))
+ dev->data->dev_conf.rxmode.jumbo_frame = 1;
if ((dev->data->dev_conf.rxmode.jumbo_frame) &&
(dev->data->dev_conf.rxmode.max_rx_pkt_len >
(mb_len - RTE_PKTMBUF_HEADROOM))) {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net/i40e: fix fdir configure failed issue in X710
From: Wu, Jingjing @ 2016-10-24 8:59 UTC (permalink / raw)
To: Guo, Jia, Zhang, Helin; +Cc: dev@dpdk.org, Yigit, Ferruh
In-Reply-To: <1476931699-44095-1-git-send-email-jia.guo@intel.com>
> -----Original Message-----
> From: Guo, Jia
> Sent: Thursday, October 20, 2016 10:48 AM
> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: [PATCH] net/i40e: fix fdir configure failed issue in X710
>
> The correct way to distinguish the behavior of X722 and X710
> or other NICs should be using the mac type but not X722 macro.
>
The code change looks fine, but the commit log looks Just don't know what the fdir configuration failure is.
Could you describe it in your commit log?
And a minor comment is like
I40E_RSS_HENA_ALL seems a part of I40E_RSS_HENA_ALL_X722, why not
#define I40E_RSS_HENA_ALL_ X722 I40E_RSS_HENA_ALL | I40E_FILTER_PCTYPE_XX
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH] net/i40e: fix the hash filter invalid calculation in X722
From: Wu, Jingjing @ 2016-10-24 9:10 UTC (permalink / raw)
To: Guo, Jia, Zhang, Helin; +Cc: dev@dpdk.org, Yigit, Ferruh
In-Reply-To: <1476931738-44140-1-git-send-email-jia.guo@intel.com>
> -----Original Message-----
> From: Guo, Jia
> Sent: Thursday, October 20, 2016 10:49 AM
> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Cc: dev@dpdk.org; Guo, Jia <jia.guo@intel.com>; Yigit, Ferruh <ferruh.yigit@intel.com>
> Subject: [PATCH] net/i40e: fix the hash filter invalid calculation in X722
>
> As X722 extracts IPv4 header to Field Vector different with XL710/X710,
> need to corresponding to modify the fields of IPv4 header in input set
> to map different default Field Vector Table of different NICs.
> Signed-off-by: Jeff Guo <jia.guo@intel.com>
> ---
> v3:
> remove the x722 macro
> v2:
> fix compile error when x722 macro is not defined and simplify
> the code to avoid duplication.
> ---
> drivers/net/i40e/i40e_ethdev.c | 60 +++++++++++++++++++++++++++++++++---------
> 1 file changed, 47 insertions(+), 13 deletions(-)
>
How about change the commit log it like:
When verifying the Hash filtering on X722, we found the behavior was not expected. For example, the hash value in descriptor is incorrect.
That was because X722 uses different way of hash key word selection comparing with X710/XL710.
This patch fixes it by setting X722 specific key selection.
And few minor comments:
If this is not the first patch, please use [PATCH v3] instead of [PATCH].
And the fixes line is missed.
Thanks
Jingijng
^ permalink raw reply
* Re: [PATCH] doc: announce ABI change for ethtool app enhance
From: Wu, Jingjing @ 2016-10-24 9:23 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org; +Cc: Yang, Qiming
In-Reply-To: <1475983002-72869-1-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Sunday, October 9, 2016 11:17 AM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH] doc: announce ABI change for ethtool app enhance
>
> This patch adds a notice that the ABI change for ethtool app to
> get the NIC firmware version in the 17.02 release.
>
> Signed-off-by: Qiming Yang <qiming.yang@intel.com>
> ---
> doc/guides/rel_notes/deprecation.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index 845d2aa..60bd7ed 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -62,3 +62,7 @@ Deprecation Notices
> * API will change for ``rte_port_source_params`` and ``rte_port_sink_params``
> structures. The member ``file_name`` data type will be changed from
> ``char *`` to ``const char *``. This change targets release 16.11.
> +
> +* In 17.02 ABI change is planned: the ``rte_eth_dev_info`` structure
> + will be extended with a new member ``fw_version`` in order to store
> + the NIC firmware version.
> --
> 2.7.4
Acked-by: Jingjing Wu <jingjing.wu@intel.com>
^ permalink raw reply
* Re: [PATCH 1/2] net/i40e: fix link status change interrupt
From: Wu, Jingjing @ 2016-10-24 9:32 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org; +Cc: Yang, Qiming
In-Reply-To: <1476338840-50003-1-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Thursday, October 13, 2016 2:07 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH 1/2] net/i40e: fix link status change interrupt
>
> Previously, link status interrupt in i40e is achieved by checking
> LINK_STAT_CHANGE_MASK in PFINT_ICR0 register which is provided only
> for diagnostic use. Instead, drivers need to get the link status
> change notification by using LSE (Link Status Event).
>
> This patch enables LSE and calls LSC callback when the event is
> received. This patch also removes the processing on
> LINK_STAT_CHANGE_MASK.
Good description! Thanks!
> Fixes: 5c9222058df7 ("i40e: move to drivers/net/")
Acked-by: Jingjing Wu <jingjing.wu@intel.com> with minor comment:
The commit 5c9222058df7 ("i40e: move to drivers/net/") is just a moving i40e PMD driver code to current folder. It is not exactly that introduced the issue.
Maybe what you are looking for is 4861cde46116 ("i40e: new poll mode driver")
Thanks
Jingjing
^ permalink raw reply
* Re: [PATCH 2/2] net/i40e: fix VF bonded device link down
From: Wu, Jingjing @ 2016-10-24 9:50 UTC (permalink / raw)
To: Yang, Qiming, dev@dpdk.org; +Cc: Yang, Qiming
In-Reply-To: <1476338840-50003-2-git-send-email-qiming.yang@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiming Yang
> Sent: Thursday, October 13, 2016 2:07 PM
> To: dev@dpdk.org
> Cc: Yang, Qiming <qiming.yang@intel.com>
> Subject: [dpdk-dev] [PATCH 2/2] net/i40e: fix VF bonded device link down
>
> Originally, using DPDK as host driver, when VF bonded device
> uses I40E_VIRTCHNL_OP_GET_LINK_STAT to query PF the link status,
If VF device is used as slave of a bond device, it will be polled periodically though alarm. Interrupt is involved here.
And then VF will send I40E_VIRTCHNL_OP_GET_LINK_STAT message to PF to get the status. The response is handled by interrupt callback. Interrupt is involved here again. That's what bond device cannot bring up.
> This patch uses PF to notify link status instead of VF query.
This patch changes like that remove I40E_VIRTCHNL_OP_GET_LINK_STAT message, link status in VF driver is updated when PF driver notify it, and VF stores the links status locally. VF driver just returns the local status when being required.
> Fixes: 5c9222058df7 ("i40e: move to drivers/net/")
The same comments as your previous patch. It is not exact commit introduced this issue.
Thanks
Jingjing
^ permalink raw reply
* Re: rte_kni_tx_burst() hangs because of no freedescriptors
From: yingzhi @ 2016-10-24 10:38 UTC (permalink / raw)
To: Zhang, Helin; +Cc: dev@dpdk.org
In-Reply-To: <F35DEAC7BCE34641BA9FAC6BCA4A12E717F2B137@SHSMSX103.ccr.corp.intel.com>
Hi Helin,
Thanks for your response, to answer your questions:
1. we send only one packet each time calling rte_kni_tx_burst(), which means the last argument is 1.
2. it returns 0 because the free mbuf function inside tx_burst will not free any mbuf:
if (txq->nb_tx_free < txq->tx_free_thresh)
ixgbe_tx_free_bufs(txq);
after this operation, the txq->nb_tx_free is not increased and keeps to be "0" eventually.
I did some tests today, I commented out this section of ixgbe_rxtx_vec_common.h -> ixgbe_tx_free_bufs
status = txq->tx_ring[txq->tx_next_dd].wb.status;
if (!(status & IXGBE_ADVTXD_STAT_DD))
return 0;
After ignoring DD bit check, our app runs for about 6 hours without issue. I suspect there is something wrong in my program set the DD bit somewhere. One of the possible cause currently I suspect is as far as I know, rte_pktmbuf_free(mbuf.array[k]) will free the mbuf of the packet and any fragmented packets following by it. But in our application such as below code snippet:
auto nb_tx = rte_eth_tx_burst(port, queue, mbuf.array, (uint16_t) nb_rx);
if (unlikely(nb_tx < nb_rx)) {
for (unsigned k = nb_tx; k < nb_rx; k++) {
rte_pktmbuf_free(mbuf.array[k]);
}
}
In this case if there are fragmented packets and failed transmission, may cause a mbuf be freed multiple times.
Above is just my suspect, need to do some tests later today or tomorrow.
Thanks
------------------ Original ------------------
From: "Zhang, Helin";<helin.zhang@intel.com>;
Date: Mon, Oct 24, 2016 11:33 AM
To: "yingzhi"<kaitoy@qq.com>;
Cc: "dev@dpdk.org"<dev@dpdk.org>;
Subject: RE: [dpdk-dev] rte_kni_tx_burst() hangs because of no freedescriptors
Hi Yingzhi
Thank you for the reporting! The description is not so clear at least for me.
Please help to narrown down the issue by youself.
How many packets would it have for calling TX function?
Why it would return 0 after calling TX function? No memory? Or return from else? Have you found anything?
Regards,
Helin
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of yingzhi
> Sent: Sunday, October 23, 2016 9:30 PM
> To: users; dev@dpdk.org
> Subject: [dpdk-dev] rte_kni_tx_burst() hangs because of no free descriptors
>
> -
> Hi Experts,
>
> Background:
>
> We are using DPDK to develop a LoadBalancer following below logic: When
> a new packet is received:
> 1. if the dst_addr is management IP, forward to KNI. 2. if the dst_addr is in
> VIP list, select backend and forward(modify dst mac address). 3. otherwise
> drop the packet.
>
> At this stage, we use one single thread for KNI forwarding and another for
> VIP forwarding(forward to eth).
>
> DPDK version: 16.07
> NIC: 82599ES 10-Gigabit SFI/SFP+ Network Connection
> Linux: 14.04.1-Ubuntu x64
>
> Promblem description:
>
> The program runs correctly for sometime(around 2 hours for 400Mb traffic).
> But it it will hang. When problem happens, rte_eth_tx_burst() will not able to
> send out any packets(always returns 0). We tracked into that function and
> noticed it is actually calling ixgbe driver's ixgbe_xmit_pkts_vec() function in
> our environment, because we use default tx queue configuration, after
> printing some info, we found if the free function works fine:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 31
>
> it will trigger free and make 32 more free descriptors:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 62
>
> but when something going wrong, it will no longer free anything:
> tx_rs_thresh: 32, tx_free_thresh: 32, nb_tx_free: 0 tx_rs_thresh: 32,
> tx_free_thresh: 32, nb_tx_free: 0
>
> It may related with the DD flag of the descriptor but we are not quite sure.
>
> Our program logic:
>
> create two mbuf pools on socket 0, one for rx_queue and one for kni. (all
> lcore threads runs on socket0)
>
> init kni interface with rte_kni_alloc()
>
>
> init one NIC interface with
> rte_eth_dev_configure(); rte_eth_rx_queue_setup();
> rte_eth_tx_queue_setup(); rte_eth_dev_start();
>
>
>
> in the eth main loop: (code is simplified)
> while(1) { n = rte_eth_rx_burst(packets); for (i = 0; i < n; ++i) { if
> (SEND_TO_KNI) { m = rte_kni_tx_burst(packets[i]); if (m != 1))
> { rte_pktmbuf_free(packets[i]); } } if (SEND_TO_ETH)
> { // after modify the packet m = rte_eth_tx_burst(packets[i]);
> if (m != 1)) { rte_pktmbuf_free(packets[i]); } } //
> otherwise drop the packet rte_pktmbuf_free(packets[i]); } }
>
>
> Please advise if I'm using DPDK in a wrong way. Sorry if I missed something
> basic, I'm new to DPDK.
>
> Thanks in advance
> Best regards
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox