Re: [dpdk-dev] technical board meeting minutes 2017-01-25
2017-01-26 23:14, St Leger, Jim: > It can be decided to remove a member if there is an approval of 2/3 of the > whole technical board. > It can be decided either to replace the member, or to redefine the size of > the board. > > > [>] Did you decide how the discussion or topic to remove a board > > member ever even comes up to begin with? > > [>] For example, does someone propose "I think we should remove > > so-and-so from the TSC/TechBoard" and then the board votes? > > I think this step will be very rare (maybe never), but it's important to > > know how/when the removal process can be initiated and if limited by who? > > (e.g. can anyone in the community suggest to remove someone? Can only > > TechBoard/TSC members suggest to remove someone? What board member behavior > > would justify removal?) The global idea of the technical board is to discuss and answer to the questions asked by anyone. So yes, anyone can suggest the removal of any member of the technical board. We will write the process on the website. > We have chosen (with global consensus) 3 new members to join the technical > board. > They will be announced soon when we will have their agreement. > The new board will probably count 9 members. > > > [>] What is the delay in announcing the new members? Is it so important to have a formal delay? We just need to get an agreement from the new members, and sometimes (as today) people may be in holidays. > [>] Not to be flippant, but the LF governance discussion and especially > budget includes line items for funding events such as DPDK Summit Userspace. > But if we can't get a point of agreement on the budget, get to an agreement > on membership fees, and recruit enough member companies to the project, then > future events will be dependent on our ability to raise sponsorship funds > across the community. Efforts to do this in the past have only shown support > from Intel, Red Hat, and Cisco. No other company has yet agreed to help > financially sponsor any of the Summit events. Got it. > * Should we have regular meetings? > We do not want to spend too many time in meetings. > However a short meeting (less than a hour) every two weeks may be relevant. > > [>] I assume you are referring solely to the TechBoard/TSC meeting. Yes, this whole discussion is only about the technical board. > * Should we organize regular public IRC meetings? > It does not scale to have too many participants in a meeting. > In order to keep meetings short, they will be private. > Everybody can discuss on the mailing list. > > [>] Are you referring to TSC/TechBoard meetings here too? Or are you > referring to regular community calls? > If community calls, I disagree and believe there should be a regular > community project call to discuss any/all issues. Items that go back and > forth many times on the mailing list could be resolved in a community call > with verbal discussion in just a few minutes. Other key topics such as RFCs > and others could also be discussed to help drive better resource alignment > and priorities for the community. There are many benefits of a DPDK Project > weekly community call, though some meetings might be quite short while others > longer (but all less than an hour.) We were talking about technical board meetings. The community calls are different things.
Re: [dpdk-dev] [PATCH] crypto/qat: make PCI device id struct const
> -Original Message-
> From: Shreyansh Jain [mailto:shreyansh.j...@nxp.com]
> Sent: Friday, January 27, 2017 7:11 AM
> To: Yigit, Ferruh
> Cc: dev@dpdk.org; Thomas Monjalon; De Lara Guarch, Pablo
> Subject: Re: [PATCH] crypto/qat: make PCI device id struct const
>
> On Thursday 26 January 2017 07:37 PM, Ferruh Yigit wrote:
> > Signed-off-by: Ferruh Yigit
> > ---
> > drivers/crypto/qat/rte_qat_cryptodev.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/crypto/qat/rte_qat_cryptodev.c
> b/drivers/crypto/qat/rte_qat_cryptodev.c
> > index 9594067..a492dc0 100644
> > --- a/drivers/crypto/qat/rte_qat_cryptodev.c
> > +++ b/drivers/crypto/qat/rte_qat_cryptodev.c
> > @@ -67,7 +67,7 @@ static struct rte_cryptodev_ops crypto_qat_ops = {
> > * The set of PCI devices this driver supports
> > */
> >
> > -static struct rte_pci_id pci_id_qat_map[] = {
> > +static const struct rte_pci_id pci_id_qat_map[] = {
> > {
> > RTE_PCI_DEVICE(0x8086, 0x0443),
> > },
> >
>
> Acked-by: Shreyansh Jain
Applied to dpdk-next-crypto.
Thanks,
Pablo
Re: [dpdk-dev] [PATCH] drivers/net: make PCI device id struct const
On 1/27/2017 7:10 AM, Shreyansh Jain wrote: > On Thursday 26 January 2017 07:37 PM, Ferruh Yigit wrote: >> Signed-off-by: Ferruh Yigit >> --- >> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++-- >> drivers/net/bnxt/bnxt_ethdev.c | 2 +- >> drivers/net/cxgbe/cxgbe_ethdev.c | 2 +- >> drivers/net/ena/ena_ethdev.c | 2 +- >> drivers/net/nfp/nfp_net.c| 2 +- >> drivers/net/qede/qede_ethdev.c | 4 ++-- >> 6 files changed, 8 insertions(+), 8 deletions(-) >> > > Do you think making this change in test_pci.c also makes sense? Yes it does, I will send a patch, thanks. > Either way: > > Acked-by: Shreyansh Jain >
Re: [dpdk-dev] [dpdk-users] net/i40e: TX descriptor is not done
Mbufs are not being freed inside the ring fast enough to accommodate the incoming traffic.
[dpdk-dev] [PATCH] app/test: make PCI device id struct const
Signed-off-by: Ferruh Yigit
---
app/test/test_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test/test_pci.c b/app/test/test_pci.c
index cda186d..7985376 100644
--- a/app/test/test_pci.c
+++ b/app/test/test_pci.c
@@ -66,12 +66,12 @@ static int my_driver_init(struct rte_pci_driver *dr,
struct rte_pci_device *dev);
/* IXGBE NICS */
-struct rte_pci_id my_driver_id[] = {
+const struct rte_pci_id my_driver_id[] = {
{RTE_PCI_DEVICE(0x0001, 0x1234)},
{ .vendor_id = 0, /* sentinel */ },
};
-struct rte_pci_id my_driver_id2[] = {
+const struct rte_pci_id my_driver_id2[] = {
{RTE_PCI_DEVICE(0x0001, 0x)},
{RTE_PCI_DEVICE(0x0002, 0xabcd)},
{ .vendor_id = 0, /* sentinel */ },
--
2.9.3
Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven programming model
On Thu, Jan 26, 2017 at 08:39:57PM +, Eads, Gage wrote: > > > > -Original Message- > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Thursday, January 26, 2017 3:39 AM > > To: Eads, Gage > > Cc: Richardson, Bruce ; 'dev@dpdk.org' > > ; 'thomas.monja...@6wind.com' > > ; 'hemant.agra...@nxp.com' > > ; Van Haaren, Harry > > ; McDaniel, Timothy > > > > Subject: Re: [dpdk-dev] [PATCH v4 1/6] eventdev: introduce event driven > > programming model > > > > On Wed, Jan 25, 2017 at 10:36:21PM +, Eads, Gage wrote: > > > > > > > Subject: [dpdk-dev] [PATCH > > > > v4 > 1/6] eventdev: introduce event driven > > programming model > > > > > > > > > +/** > > + * Enqueue > > > > a burst > of events objects or an event object supplied > > in > > > > > > > *rte_event* > > + * structure on an event device designated > > > > by its > *dev_id* > > through the event + * port specified by > > > > *port_id*. Each > event > > object specifies the event queue on + > > > > * which it will be > enqueued. > > > > > > > + * > > > > > > > + * The *nb_events* parameter is the number of event > > > > objects to > > > enqueue which are + * supplied in the *ev* array > > > > of *rte_event* > > > structure. > > > > > > > + * > > > > > > > + * The rte_event_enqueue_burst() function returns the > > > > number of > + > > * events objects it actually enqueued. A return > > > > value equal to > > > *nb_events* + * means that all event objects > > have > > been enqueued. > > > > > > > + * > > > > > > > + * @param dev_id > > > > > > > + * The identifier of the device. > > > > > > > + * @param port_id > > > > > > > + * The identifier of the event port. > > > > > > > + * @param ev > > > > > > > + * Points to an array of *nb_events* objects of type > > *rte_event* > > > > > > structure > > > > > > > + * which contain the event object enqueue operations to be > > > > > > processed. > > > > > > > + * @param nb_events > > > > > > > + * The number of event objects to enqueue, typically > > number of > > > > > > > + * rte_event_port_enqueue_depth() available for this port. > > > > > > > + * > > > > > > > + * @return > > > > > > > + * The number of event objects actually enqueued on the > > event > > > > > > device. The > > > > > > > + * return value can be less than the value of the > > *nb_events* > > > > > > parameter > > > > > > > when > > > > > > > + * the event devices queue is full or if invalid > > parameters are > > > > > > specified in a > > > > > > > + * *rte_event*. If return value is less than *nb_events*, > > the > > > > > > remaining events > > > > > > > + * at the end of ev[] are not consumed,and the caller has > > to take > > > > > > care of > > > > > > > them > > > > > > > + * > > > > > > > + * @see rte_event_port_enqueue_depth() + */ +uint16_t > > > > > > > +rte_event_enqueue_burst(uint8_t dev_id, uint8_t port_id, > > > > > > > + const struct rte_event ev[], uint16_t > > nb_events); > > > > > > > > > > > > There are a number of reasons this operation could fail to > > > > enqueue > all > the events, including: > > > > > > - Backpressure > > > > > > - Invalid port ID > > > > > > - Invalid queue ID > > > > > > - Invalid sched type when a queue is configured for > > > > ATOMIC_ONLY, > > ORDERED_ONLY, or PARALLEL_ONLY > - ... > > > > > > > > > > > > The current API doesn't provide a straightforward way to > > > > determine > the > cause of a failure. This is a particular issue > > > > on event PMDs > that can > backpressure, where the app may want to > > > > treat that case > differently > than the other failure cases. > > > > > > > > > > > > Could we change the return type to int16_t, and define a set > > > > of > error > cases (e.g. -ENOSPC for backpressure, -EINVAL for an > > > > invalid argument)? > > > > > > (With corresponding changes needed in the PMD API) Similarly > > > > we > could > change rte_event_dequeue_burst() to return an > > > > int16_t, with > -EINVAL as > a possible error case. > > > > > > > > > > Use rte_errno instead, I suggest. That's what it's there for. > > > > > > > > > > /Bruce > > > > > > > > That makes sense. In that case, the API comment could be tweaked like > > so: > > > > > > > >* If the return value is less than *nb_events*, the remaining > > events at the > > > >* end of ev[] are not consumed and the caller has to take care of > > them, > > and > > > >* rte_errno is set accordingly. Possible errno values include: > > > >* - EINVAL - The port ID is invalid, an event's queue ID is > > invalid, or an > > > >*event's sched type doesn't match the capabilities of > > the > > > >*destination queue. > >
Re: [dpdk-dev] Understanding of Acked-By
On Fri, Jan 27, 2017 at 12:48:06PM +0530, Shreyansh Jain wrote: > On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote: > > 2017-01-25 13:53, Van Haaren, Harry: > > > There was an idea (from Thomas) to better document the Acked-by and > > > Reviewed-By in the above thread, which I think is worth doing to make the > > > process clearer. I'll kick off a thread*, and offer to submit a patch for > > > the documentation when a consensus is reached. > > > > > > > > > The question that needs to be addressed is "What is the most powerful > > > signoff to add as somebody who checked a patch?" > > > > I do not see the benefit of knowing the most powerful. > > Anyway, the most powerful tags are done by trusted people. > > And people are trusted after delivering good reviews or patches ;) > > > > The question should be "How to use the tags?" > > > > > The documentation mentions Acked, Reviewed, and Tested by[1], as signoffs > > > that can be commented on patches. The Review Process[2] section mentions > > > Reviewed and Tested by, but nowhere specifically states what any of these > > > indicate. > > > > > > Offered below is my current understanding of the Acked-by; Reviewed-by; > > > and Tested-by tags, in order of least-powerful first: > > > > > > > > > 3) Tested-by: (least powerful) > > > - Indicates having passed testing of functionality, and works as > > > expected for Tester > > > - Does NOT include full code review (instead use Reviewed by) > > > - Does NOT indicate that the Tester understands architecture (instead > > > use Acked by) > > > > > > > > > 2) Reviewed-by: > > > - Indicates having passed code-review, checkpatch and compilation > > > testing by Reviewer > > > > Compilation testing is done by the CI. > > The reviewer must just check the results. > > > > > - Does NOT include full testing of functionality (instead use Tested-by) > > > - Does NOT indicate that the Reviewer understands architecture (instead > > > use Acked by) > > > > I disagree here. > > The reviewer must understand the impacts of the patch. > > That's why a Reviewed-by tag is really strong. > > From what I understand, 'Reviewed-by' and 'Acked-by' are the other way > around. > - Acked-by is intent that 'I agree with change'. > - Reviewed-by is 'I vouch for the changes' either through review or > testing or both. > Other way round in what way - compared to proposed by Harry or by Thomas? Which do you view as the stronger indication that the patch is ok? Regards, /Bruce
Re: [dpdk-dev] Understanding of Acked-By
On Friday 27 January 2017 03:43 PM, Bruce Richardson wrote: On Fri, Jan 27, 2017 at 12:48:06PM +0530, Shreyansh Jain wrote: On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote: 2017-01-25 13:53, Van Haaren, Harry: There was an idea (from Thomas) to better document the Acked-by and Reviewed-By in the above thread, which I think is worth doing to make the process clearer. I'll kick off a thread*, and offer to submit a patch for the documentation when a consensus is reached. The question that needs to be addressed is "What is the most powerful signoff to add as somebody who checked a patch?" I do not see the benefit of knowing the most powerful. Anyway, the most powerful tags are done by trusted people. And people are trusted after delivering good reviews or patches ;) The question should be "How to use the tags?" The documentation mentions Acked, Reviewed, and Tested by[1], as signoffs that can be commented on patches. The Review Process[2] section mentions Reviewed and Tested by, but nowhere specifically states what any of these indicate. Offered below is my current understanding of the Acked-by; Reviewed-by; and Tested-by tags, in order of least-powerful first: 3) Tested-by: (least powerful) - Indicates having passed testing of functionality, and works as expected for Tester - Does NOT include full code review (instead use Reviewed by) - Does NOT indicate that the Tester understands architecture (instead use Acked by) 2) Reviewed-by: - Indicates having passed code-review, checkpatch and compilation testing by Reviewer Compilation testing is done by the CI. The reviewer must just check the results. - Does NOT include full testing of functionality (instead use Tested-by) - Does NOT indicate that the Reviewer understands architecture (instead use Acked by) I disagree here. The reviewer must understand the impacts of the patch. That's why a Reviewed-by tag is really strong. From what I understand, 'Reviewed-by' and 'Acked-by' are the other way around. - Acked-by is intent that 'I agree with change'. - Reviewed-by is 'I vouch for the changes' either through review or testing or both. Other way round in what way - compared to proposed by Harry or by Thomas? Which do you view as the stronger indication that the patch is ok? Sorry, I should have posted this against Harry's mail rather than Thomas'. 'Other way round' as compared to Harry's text. Reviewed-by is a strong indication, in my understanding. Regards, /Bruce - Shreyansh
[dpdk-dev] [PATCH v6 1/3] net/i40e: fix segmentation fault in close
Change the order of releasing the vsi's.
Release the vmdq vsi's first, then release the main vsi.
Fixes: 4861cde46116 ("i40e: new poll mode driver")
CC: sta...@dpdk.org
Signed-off-by: Bernard Iremonger
Acked-by: Jingjing Wu
---
Changes in v6:
Rebased to latest dpdk-next-net
This was previously part of a patchset with testpmd patches.
Sending seperately as the testpmd patches have not been acked yet.
drivers/net/i40e/i40e_ethdev.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index a818998..0937dc4 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -2072,18 +2072,17 @@ i40e_dev_close(struct rte_eth_dev *dev)
/* shutdown and destroy the HMC */
i40e_shutdown_lan_hmc(hw);
- /* release all the existing VSIs and VEBs */
- i40e_fdir_teardown(pf);
- i40e_vsi_release(pf->main_vsi);
-
for (i = 0; i < pf->nb_cfg_vmdq_vsi; i++) {
i40e_vsi_release(pf->vmdq[i].vsi);
pf->vmdq[i].vsi = NULL;
}
-
rte_free(pf->vmdq);
pf->vmdq = NULL;
+ /* release all the existing VSIs and VEBs */
+ i40e_fdir_teardown(pf);
+ i40e_vsi_release(pf->main_vsi);
+
/* shutdown the adminq */
i40e_aq_queue_shutdown(hw, true);
i40e_shutdown_adminq(hw);
@@ -4374,6 +4373,9 @@ i40e_vsi_release(struct i40e_vsi *vsi)
if (!vsi)
return I40E_SUCCESS;
+ if (!vsi->adapter)
+ return -EFAULT;
+
user_param = vsi->user_param;
pf = I40E_VSI_TO_PF(vsi);
--
2.10.1
Re: [dpdk-dev] Understanding of Acked-By
> -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shreyansh Jain > Sent: Friday, January 27, 2017 10:25 AM > To: Richardson, Bruce > Cc: Thomas Monjalon ; Van Haaren, Harry > ; dev@dpdk.org; Yigit, Ferruh > ; Igor Ryzhov ; Steve Shin > > Subject: Re: [dpdk-dev] Understanding of Acked-By > > On Friday 27 January 2017 03:43 PM, Bruce Richardson wrote: > > On Fri, Jan 27, 2017 at 12:48:06PM +0530, Shreyansh Jain wrote: > >> On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote: > >>> 2017-01-25 13:53, Van Haaren, Harry: > There was an idea (from Thomas) to better document the Acked-by and > Reviewed-By in the above thread, which I think is worth doing to make the > process clearer. I'll kick off a thread*, and offer to submit a patch for > the documentation when a consensus is reached. > > > The question that needs to be addressed is "What is the most powerful > signoff to add as somebody who checked a patch?" > >>> > >>> I do not see the benefit of knowing the most powerful. > >>> Anyway, the most powerful tags are done by trusted people. > >>> And people are trusted after delivering good reviews or patches ;) > >>> > >>> The question should be "How to use the tags?" > >>> > The documentation mentions Acked, Reviewed, and Tested by[1], as > signoffs that can be commented on patches. The Review Process[2] section > mentions Reviewed and Tested by, but nowhere specifically states what any > of these indicate. > > Offered below is my current understanding of the Acked-by; Reviewed- > by; and Tested-by tags, in order of least-powerful first: > > > 3) Tested-by: (least powerful) > - Indicates having passed testing of functionality, and works as > expected for Tester > - Does NOT include full code review (instead use Reviewed by) > - Does NOT indicate that the Tester understands architecture > (instead use Acked by) > > > 2) Reviewed-by: > - Indicates having passed code-review, checkpatch and compilation > testing by Reviewer > >>> > >>> Compilation testing is done by the CI. > >>> The reviewer must just check the results. > >>> > - Does NOT include full testing of functionality (instead use > Tested-by) > - Does NOT indicate that the Reviewer understands architecture > (instead use Acked by) > >>> > >>> I disagree here. > >>> The reviewer must understand the impacts of the patch. > >>> That's why a Reviewed-by tag is really strong. > >> > >> From what I understand, 'Reviewed-by' and 'Acked-by' are the other > >> way around. > >> - Acked-by is intent that 'I agree with change'. > >> - Reviewed-by is 'I vouch for the changes' either through review or > >> testing or both. > >> > > > > Other way round in what way - compared to proposed by Harry or by > > Thomas? Which do you view as the stronger indication that the patch is > > ok? > > Sorry, I should have posted this against Harry's mail rather than Thomas'. > 'Other way round' as compared to Harry's text. > Reviewed-by is a strong indication, in my understanding. Hi, Maybe we should just follow the Kernel guidelines on this: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-and-cc And to, save-you-a-click(tm) here is the relevant sections of the doc: 12) When to use Acked-by: and Cc: - The Signed-off-by: tag indicates that the signer was involved in the development of the patch, or that he/she was in the patch's delivery path. If a person was not directly involved in the preparation or handling of a patch but wishes to signify and record their approval of it then they can ask to have an Acked-by: line added to the patch's changelog. Acked-by: is often used by the maintainer of the affected code when that maintainer neither contributed to nor forwarded the patch. Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance. Hence patch mergers will sometimes manually convert an acker's "yep, looks good to me" into an Acked-by: (but note that it is usually better to ask for an explicit ack). Acked-by: does not necessarily indicate acknowledgement of the entire patch. For example, if a patch affects multiple subsystems and has an Acked-by: from one subsystem maintainer then this usually indicates acknowledgement of just the part which affects that maintainer's code. Judgement should be used here. When in doubt people should refer to the original discussion in the mailing list archives. If a person has had the opportunity to comment on a patch, but has not provided such comments, you may optionally add a ``Cc:`` tag to the patch. This is the only tag which might be added without an explicit action by the person it names - but it should indicate that this person was copied on the patch. This tag documents that potentially interested par
[dpdk-dev] [PATCH v6 1/2] app/testpmd: add command to configure VMDq
Add the following command to configure VMDq:
port config vmdq
Add the following command to set number of pools:
set nbpool
Add new commands to testpmd user guide.
Signed-off-by: Bernard Iremonger
---
app/test-pmd/cmdline.c | 72 -
app/test-pmd/config.c | 14 +-
app/test-pmd/parameters.c | 15 +-
app/test-pmd/testpmd.c | 220 +++-
app/test-pmd/testpmd.h | 7 +-
doc/guides/testpmd_app_ug/testpmd_funcs.rst | 18 ++-
6 files changed, 334 insertions(+), 12 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 2fd862f..f017833 100644
--- a/app/test-pmd/cmdline.c
+++ b/app/test-pmd/cmdline.c
@@ -1,7 +1,7 @@
/*-
* BSD LICENSE
*
- * Copyright(c) 2010-2016 Intel Corporation. All rights reserved.
+ * Copyright(c) 2010-2017 Intel Corporation. All rights reserved.
* Copyright(c) 2014 6WIND S.A.
* All rights reserved.
*
@@ -238,6 +238,9 @@ static void cmd_help_long_parsed(void *parsed_result,
"set nbcore (num)\n"
"Set number of cores.\n\n"
+ "set nbpool (num)\n"
+ "Set number of VMDq pools.\n\n"
+
"set coremask (mask)\n"
"Set the forwarding cores hexadecimal mask.\n\n"
@@ -629,6 +632,9 @@ static void cmd_help_long_parsed(void *parsed_result,
" pfc (on|off)\n"
"Set the DCB mode.\n\n"
+ "port config (port_id) vmdq\n"
+ "Configure VMDq for a port.\n\n"
+
"port config all burst (value)\n"
"Set the number of packets per burst.\n\n"
@@ -2322,6 +2328,61 @@ cmdline_parse_inst_t cmd_config_dcb = {
},
};
+/* *** Configure VMDq *** */
+struct cmd_config_vmdq {
+ cmdline_fixed_string_t port;
+ cmdline_fixed_string_t config;
+ uint8_t port_id;
+ cmdline_fixed_string_t vmdq;
+};
+
+static void
+cmd_config_vmdq_parsed(void *parsed_result,
+ __attribute__((unused)) struct cmdline *cl,
+ __attribute__((unused)) void *data)
+{
+ struct cmd_config_vmdq *res = parsed_result;
+ portid_t port_id = res->port_id;
+ struct rte_port *port;
+ int ret;
+
+ port = &ports[port_id];
+ /** Check if the port is not started **/
+ if (port->port_status != RTE_PORT_STOPPED) {
+ printf("Please stop port %d first\n", port_id);
+ return;
+ }
+
+ ret = init_port_vmdq_config(port_id);
+ if (ret != 0) {
+ printf("Cannot configure VMDQ for port %d.\n", port_id);
+ return;
+ }
+ cmd_reconfig_device_queue(port_id, 0, 0);
+}
+
+cmdline_parse_token_string_t cmd_config_vmdq_port =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, port, "port");
+cmdline_parse_token_string_t cmd_config_vmdq_config =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, config, "config");
+cmdline_parse_token_num_t cmd_config_vmdq_port_id =
+ TOKEN_NUM_INITIALIZER(struct cmd_config_vmdq, port_id, UINT8);
+cmdline_parse_token_string_t cmd_config_vmdq_vmdq =
+ TOKEN_STRING_INITIALIZER(struct cmd_config_vmdq, vmdq, "vmdq");
+
+cmdline_parse_inst_t cmd_config_vmdq = {
+ .f = cmd_config_vmdq_parsed,
+ .data = NULL,
+ .help_str = "port config vmdq",
+ .tokens = {
+ (void *)&cmd_config_vmdq_port,
+ (void *)&cmd_config_vmdq_config,
+ (void *)&cmd_config_vmdq_port_id,
+ (void *)&cmd_config_vmdq_vmdq,
+ NULL,
+ },
+};
+
/* *** configure number of packets per burst *** */
struct cmd_config_burst {
cmdline_fixed_string_t port;
@@ -2722,7 +2783,7 @@ cmdline_parse_inst_t cmd_set_fwd_mask = {
};
/*
- * SET NBPORT, NBCORE, PACKET BURST, and VERBOSE LEVEL CONFIGURATION
+ * SET NBPORT, NBCORE, NBPOOL, PACKET BURST, and VERBOSE LEVEL CONFIGURATION
*/
struct cmd_set_result {
cmdline_fixed_string_t set;
@@ -2741,6 +2802,8 @@ static void cmd_set_parsed(void *parsed_result,
} else if (!strcmp(res->what, "nbcore")) {
set_fwd_lcores_number(res->value);
fwd_config_setup();
+ } else if (!strcmp(res->what, "nbpool")) {
+ set_vmdq_pool_number(res->value);
} else if (!strcmp(res->what, "burst"))
set_nb_pkt_per_burst(res->value);
else if (!strcmp(res->what, "verbose"))
@@ -2751,14 +2814,14 @@ cmdline_parse_token_string_t cmd_set_set =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, set, "set");
cmdline_parse_token_string_t cmd_set_what =
TOKEN_STRING_INITIALIZER(struct cmd_set_result, what,
-"nbport#nbcore#burst#verbose");
+
[dpdk-dev] [PATCH v6 2/2] app/testpmd: fix port stop
The rte_eth_dev_stop function is not called if the port_status is
not RTE_PORT_STARTED. This can happen if the rte_eth_dev_start
function is called directly, ie not through the start_port function.
Make sure rte_eth_dev_stop is always called in stop_port function.
Fixes: ce8d561418d4 ("app/testpmd: add port configuration settings")
CC: sta...@dpdk.org
Signed-off-by: Bernard Iremonger
---
app/test-pmd/testpmd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 3d25436..0d7a4d4 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1490,13 +1490,13 @@ stop_port(portid_t pid)
continue;
}
+ rte_eth_dev_stop(pi);
+
port = &ports[pi];
if (rte_atomic16_cmpset(&(port->port_status), RTE_PORT_STARTED,
RTE_PORT_HANDLING) == 0)
continue;
- rte_eth_dev_stop(pi);
-
if (rte_atomic16_cmpset(&(port->port_status),
RTE_PORT_HANDLING, RTE_PORT_STOPPED) == 0)
printf("Port %d can not be set into stopped\n", pi);
--
2.10.1
[dpdk-dev] [PATCH v6 0/2] app/testpmd: enable VMDq in testpmd
Changes in v6: Rebased to latest dpdk-next-net Removed i40e patch from this patchset and sent it as a standalone patch. Fixed checkpatch warning in testpmd.c. Changes in v5: Rebase to latest dpdk-next-net Reworked init_port_vmdq_config() function in testpmd. Added patch 3, fix to stop_port() function in testpmd. Changes in v4: Rebase to latest dpdk-next-net Replaced I40E_ERR_BAD_PTR with -EFAULT. Changes in v3 Fix checkpatch warning in testpmd.c Tidy debug code in testpmd.c Changes in v2: These two patches were previously part of the following patchset: [PATCH v7 00/27] Support VFD on i40e They are being submitted seperately as they are not needed for VFD. The net/i40e patch has been revised. The testpmd patch is needed to setup VMDq in order to test the fix. Bernard Iremonger (2): app/testpmd: add command to configure VMDq app/testpmd: fix port stop app/test-pmd/cmdline.c | 72 - app/test-pmd/config.c | 14 +- app/test-pmd/parameters.c | 15 +- app/test-pmd/testpmd.c | 224 +++- app/test-pmd/testpmd.h | 7 +- doc/guides/testpmd_app_ug/testpmd_funcs.rst | 18 ++- 6 files changed, 336 insertions(+), 14 deletions(-) -- 2.10.1
Re: [dpdk-dev] Understanding of Acked-By
On 1/27/2017 10:32 AM, Mcnamara, John wrote: > > >> -Original Message- >> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Shreyansh Jain >> Sent: Friday, January 27, 2017 10:25 AM >> To: Richardson, Bruce >> Cc: Thomas Monjalon ; Van Haaren, Harry >> ; dev@dpdk.org; Yigit, Ferruh >> ; Igor Ryzhov ; Steve Shin >> >> Subject: Re: [dpdk-dev] Understanding of Acked-By >> >> On Friday 27 January 2017 03:43 PM, Bruce Richardson wrote: >>> On Fri, Jan 27, 2017 at 12:48:06PM +0530, Shreyansh Jain wrote: On Wednesday 25 January 2017 08:28 PM, Thomas Monjalon wrote: > 2017-01-25 13:53, Van Haaren, Harry: >> There was an idea (from Thomas) to better document the Acked-by and >> Reviewed-By in the above thread, which I think is worth doing to make the >> process clearer. I'll kick off a thread*, and offer to submit a patch for >> the documentation when a consensus is reached. >> >> >> The question that needs to be addressed is "What is the most powerful >> signoff to add as somebody who checked a patch?" > > I do not see the benefit of knowing the most powerful. > Anyway, the most powerful tags are done by trusted people. > And people are trusted after delivering good reviews or patches ;) > > The question should be "How to use the tags?" > >> The documentation mentions Acked, Reviewed, and Tested by[1], as >> signoffs that can be commented on patches. The Review Process[2] section >> mentions Reviewed and Tested by, but nowhere specifically states what any >> of these indicate. >> >> Offered below is my current understanding of the Acked-by; Reviewed- >> by; and Tested-by tags, in order of least-powerful first: >> >> >> 3) Tested-by: (least powerful) >> - Indicates having passed testing of functionality, and works as >> expected for Tester >> - Does NOT include full code review (instead use Reviewed by) >> - Does NOT indicate that the Tester understands architecture >> (instead use Acked by) >> >> >> 2) Reviewed-by: >> - Indicates having passed code-review, checkpatch and compilation >> testing by Reviewer > > Compilation testing is done by the CI. > The reviewer must just check the results. > >> - Does NOT include full testing of functionality (instead use >> Tested-by) >> - Does NOT indicate that the Reviewer understands architecture >> (instead use Acked by) > > I disagree here. > The reviewer must understand the impacts of the patch. > That's why a Reviewed-by tag is really strong. From what I understand, 'Reviewed-by' and 'Acked-by' are the other way around. - Acked-by is intent that 'I agree with change'. - Reviewed-by is 'I vouch for the changes' either through review or testing or both. >>> >>> Other way round in what way - compared to proposed by Harry or by >>> Thomas? Which do you view as the stronger indication that the patch is >>> ok? >> >> Sorry, I should have posted this against Harry's mail rather than Thomas'. >> 'Other way round' as compared to Harry's text. >> Reviewed-by is a strong indication, in my understanding. > > > Hi, > > Maybe we should just follow the Kernel guidelines on this: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-and-cc > > > And to, save-you-a-click(tm) here is the relevant sections of the doc: > > > 12) When to use Acked-by: and Cc: > - > > The Signed-off-by: tag indicates that the signer was involved in the > development of the patch, or that he/she was in the patch's delivery path. > > If a person was not directly involved in the preparation or handling of a > patch but wishes to signify and record their approval of it then they can > ask to have an Acked-by: line added to the patch's changelog. > > Acked-by: is often used by the maintainer of the affected code when that > maintainer neither contributed to nor forwarded the patch. > > Acked-by: is not as formal as Signed-off-by:. It is a record that the acker > has at least reviewed the patch and has indicated acceptance. I want to highlight this part. Ack means patch _at least_ reviewed, I was expecting a patch not acked without a review. That is why I believe Ack is a superset of Reviewed-by. Because it means patch is reviewed and agreed by a knowledgeable person of that area. > Hence patch > mergers will sometimes manually convert an acker's "yep, looks good to me" > into an Acked-by: (but note that it is usually better to ask for an > explicit ack). > > Acked-by: does not necessarily indicate acknowledgement of the entire patch. > For example, if a patch affects multiple subsystems and has an Acked-by: from > one subsystem maintainer then this usually indicates acknowledgement of just > the part which affects that maintainer's code. Judgement should be used here. > When in doubt people should refer to
Re: [dpdk-dev] [PATCH] drivers/net: make PCI device id struct const
On 1/27/2017 7:10 AM, Shreyansh Jain wrote: > On Thursday 26 January 2017 07:37 PM, Ferruh Yigit wrote: >> Signed-off-by: Ferruh Yigit >> --- >> drivers/net/bnx2x/bnx2x_ethdev.c | 4 ++-- >> drivers/net/bnxt/bnxt_ethdev.c | 2 +- >> drivers/net/cxgbe/cxgbe_ethdev.c | 2 +- >> drivers/net/ena/ena_ethdev.c | 2 +- >> drivers/net/nfp/nfp_net.c| 2 +- >> drivers/net/qede/qede_ethdev.c | 4 ++-- >> 6 files changed, 8 insertions(+), 8 deletions(-) >> > > Do you think making this change in test_pci.c also makes sense? > Either way: > > Acked-by: Shreyansh Jain Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/enic: fix MAC address add and remove
On 1/26/2017 8:12 PM, John Daley wrote:
> The mac_addr_add callback function was simply replacing the primary MAC
> address instead of adding new ones and the mac_addr_remove callback would
> only remove the primary MAC form the adapter. Fix the functions to add or
> remove new address. Allow up to 64 MAC addresses per port.
>
> Fixes: fefed3d1e62c ("enic: new driver")
>
> Signed-off-by: John Daley
> Reviewed-by: Nelson Escobar
Applied to dpdk-next-net/master, thanks.
(Since it is controversial that if this patch is a fix or implementing a
missing feature (allow up to 64 MAC), I am getting patch as it is, but
not CC'ed to stable tree, please shout if you disagree.)
[dpdk-dev] [PATCH] doc: update examples list for API
These files are linked to API documentation as usage samples, added missing examples files and sorted list alphabetically. Signed-off-by: Ferruh Yigit --- doc/api/examples.dox | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/doc/api/examples.dox b/doc/api/examples.dox index c13e574..2d6b65b 100644 --- a/doc/api/examples.dox +++ b/doc/api/examples.dox @@ -12,6 +12,10 @@ @example ethtool/ethtool-app/main.c @example ethtool/lib/rte_ethtool.c @example exception_path/main.c +@example flow_distributor/distributor/args.c +@example flow_distributor/distributor/init.c +@example flow_distributor/distributor/main.c +@example flow_distributor/node/node.c @example helloworld/main.c @example ip_fragmentation/main.c @example ip_pipeline/config_check.c @@ -20,6 +24,7 @@ @example ip_pipeline/cpu_core_map.c @example ip_pipeline/init.c @example ip_pipeline/main.c +@example ip_pipeline/parser.c @example ip_pipeline/pipeline/pipeline_common_be.c @example ip_pipeline/pipeline/pipeline_common_fe.c @example ip_pipeline/pipeline/pipeline_firewall_be.c @@ -37,13 +42,27 @@ @example ip_pipeline/thread.c @example ip_pipeline/thread_fe.c @example ip_reassembly/main.c +@example ipsec-secgw/esp.c +@example ipsec-secgw/ipsec.c +@example ipsec-secgw/ipsec-secgw.c +@example ipsec-secgw/parser.c +@example ipsec-secgw/rt.c +@example ipsec-secgw/sa.c +@example ipsec-secgw/sp4.c +@example ipsec-secgw/sp6.c @example ipv4_multicast/main.c @example kni/main.c +@example l2fwd-cat/cat.c +@example l2fwd-cat/l2fwd-cat.c @example l2fwd-crypto/main.c @example l2fwd-jobstats/main.c +@example l2fwd-keepalive/ka-agent/main.c @example l2fwd-keepalive/main.c +@example l2fwd-keepalive/shm.c @example l2fwd/main.c @example l3fwd-acl/main.c +@example l3fwd/l3fwd_em.c +@example l3fwd/l3fwd_lpm.c @example l3fwd/main.c @example l3fwd-power/main.c @example l3fwd-vf/main.c @@ -52,10 +71,6 @@ @example load_balancer/init.c @example load_balancer/main.c @example load_balancer/runtime.c -@example flow_distributor/distributor/args.c -@example flow_distributor/distributor/init.c -@example flow_distributor/distributor/main.c -@example flow_distributor/node/node.c @example multi_process/client_server_mp/mp_client/client.c @example multi_process/client_server_mp/mp_server/args.c @example multi_process/client_server_mp/mp_server/init.c -- 2.9.3
[dpdk-dev] [PATCH] doc: add PMD specific API
Signed-off-by: Ferruh Yigit --- doc/api/doxy-api-index.md | 4 doc/api/doxy-api.conf | 2 ++ 2 files changed, 6 insertions(+) diff --git a/doc/api/doxy-api-index.md b/doc/api/doxy-api-index.md index f9958c4..525d2e1 100644 --- a/doc/api/doxy-api-index.md +++ b/doc/api/doxy-api-index.md @@ -153,3 +153,7 @@ There are many libraries, so their headers may be grouped by topics: [ABI compat] (@ref rte_compat.h), [keepalive] (@ref rte_keepalive.h), [version](@ref rte_version.h) + +- **PMD specific**: + [ixgbe] (@ref rte_pmd_ixgbe.h), + [i40e] (@ref rte_pmd_i40e.h) diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index 6892315..b8a5fd8 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -32,6 +32,8 @@ PROJECT_NAME= DPDK INPUT = doc/api/doxy-api-index.md \ doc/api/examples.dox \ drivers/net/bonding \ + drivers/net/i40e \ + drivers/net/ixgbe \ lib/librte_eal/common/include \ lib/librte_eal/common/include/generic \ lib/librte_acl \ -- 2.9.3
[dpdk-dev] [PATCH] net/i40e: fix API comments for doxygen
Fixes: a541407fe4bc ("net/i40e: set VF MAC anti-spoofing from PF")
Fixes: 4cbc41efcbb2 ("net/i40e: set VF VLAN anti-spoofing from PF")
Fixes: c0ec14757c5f ("net/i40e: set VF unicast promiscuous mode from PF")
Fixes: ae57070ca8b7 ("net/i40e: set VF multicast promiscuous mode from PF")
Fixes: 83bb95e3fefc ("net/i40e: set VF VLAN insertion from PF")
Fixes: 61fff9b4c68b ("net/i40e: set VF broadcast mode from PF")
Fixes: c33abbc1440e ("net/i40e: set VF VLAN tag from PF")
Signed-off-by: Ferruh Yigit
---
drivers/net/i40e/rte_pmd_i40e.h | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/i40e/rte_pmd_i40e.h b/drivers/net/i40e/rte_pmd_i40e.h
index f4bd0fd..a0ad88c 100644
--- a/drivers/net/i40e/rte_pmd_i40e.h
+++ b/drivers/net/i40e/rte_pmd_i40e.h
@@ -84,7 +84,7 @@ int rte_pmd_i40e_ping_vfs(uint8_t port, uint16_t vf);
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*VF on which to set MAC anti spoofing.
* @param on
*1 - Enable VFs MAC anti spoofing.
@@ -103,7 +103,7 @@ int rte_pmd_i40e_set_vf_mac_anti_spoof(uint8_t port,
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*VF on which to set VLAN anti spoofing.
* @param on
*1 - Enable VFs VLAN anti spoofing.
@@ -138,7 +138,7 @@ int rte_pmd_i40e_set_tx_loopback(uint8_t port,
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*VF on which to set.
* @param on
*1 - Enable.
@@ -157,7 +157,7 @@ int rte_pmd_i40e_set_vf_unicast_promisc(uint8_t port,
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*VF on which to set.
* @param on
*1 - Enable.
@@ -218,7 +218,7 @@ rte_pmd_i40e_set_vf_vlan_stripq(uint8_t port, uint16_t vf,
uint8_t on);
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*ID specifying VF.
* @param vlan_id
*0 - Disable VF's vlan insert.
@@ -237,7 +237,7 @@ int rte_pmd_i40e_set_vf_vlan_insert(uint8_t port, uint16_t
vf_id,
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*ID specifying VF.
* @param on
*0 - Disable broadcast.
@@ -256,9 +256,9 @@ int rte_pmd_i40e_set_vf_broadcast(uint8_t port, uint16_t
vf_id,
*
* @param port
*The port identifier of the Ethernet device.
- * @param vf
+ * @param vf_id
*ID specifying VF.
- * @param vlan_id
+ * @param on
*0 - Disable VF's vlan tag.
*n - Enable VF's vlan tag.
*
--
2.9.3
[dpdk-dev] [PATCH] net/ixgbe: fix API comments for doxygen
Fixes: 57aa1fd284d5 ("net/ixgbe: move set VF functions from the ethdev")
Signed-off-by: Ferruh Yigit
---
drivers/net/ixgbe/rte_pmd_ixgbe.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ixgbe/rte_pmd_ixgbe.h
b/drivers/net/ixgbe/rte_pmd_ixgbe.h
index d4efe07..4d7b507 100644
--- a/drivers/net/ixgbe/rte_pmd_ixgbe.h
+++ b/drivers/net/ixgbe/rte_pmd_ixgbe.h
@@ -293,7 +293,7 @@ int rte_pmd_ixgbe_macsec_select_rxsa(uint8_t port, uint8_t
idx, uint8_t an,
* The port identifier of the Ethernet device.
* @param vf
* VF id.
-* @param rx_mode
+* @param rx_mask
*The RX mode mask, which is one or more of accepting Untagged Packets,
*packets that match the PFUTA table, Broadcast and Multicast Promiscuous.
*ETH_VMDQ_ACCEPT_UNTAG,ETH_VMDQ_ACCEPT_HASH_UC,
@@ -353,9 +353,9 @@ rte_pmd_ixgbe_set_vf_tx(uint8_t port, uint16_t vf, uint8_t
on);
* Enable/Disable hardware VF VLAN filtering by an Ethernet device of
* received VLAN packets tagged with a given VLAN Tag Identifier.
*
-* @param port id
+* @param port
* The port identifier of the Ethernet device.
-* @param vlan_id
+* @param vlan
* The VLAN Tag Identifier whose filtering must be enabled or disabled.
* @param vf_mask
*Bitmap listing which VFs participate in the VLAN filtering.
@@ -374,7 +374,7 @@ rte_pmd_ixgbe_set_vf_vlan_filter(uint8_t port, uint16_t
vlan, uint64_t vf_mask,
/**
* Set the rate limitation for a vf on an Ethernet device.
*
- * @param port_id
+ * @param port
* The port identifier of the Ethernet device.
* @param vf
* VF id.
--
2.9.3
Re: [dpdk-dev] [PATCH] doc: update examples list for API
Hi Ferruh, > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ferruh Yigit > Sent: Friday, January 27, 2017 11:56 AM > To: Mcnamara, John > Cc: dev@dpdk.org; Yigit, Ferruh > Subject: [dpdk-dev] [PATCH] doc: update examples list for API > > These files are linked to API documentation as usage samples, added > missing examples files and sorted list alphabetically. > > Signed-off-by: Ferruh Yigit > --- > doc/api/examples.dox | 23 +++ > 1 file changed, 19 insertions(+), 4 deletions(-) > > diff --git a/doc/api/examples.dox b/doc/api/examples.dox > index c13e574..2d6b65b 100644 > --- a/doc/api/examples.dox > +++ b/doc/api/examples.dox > @@ -12,6 +12,10 @@ > @example ethtool/ethtool-app/main.c > @example ethtool/lib/rte_ethtool.c > @example exception_path/main.c > +@example flow_distributor/distributor/args.c > +@example flow_distributor/distributor/init.c > +@example flow_distributor/distributor/main.c > +@example flow_distributor/node/node.c I am renaming this sample app in this patch (http://dpdk.org/dev/patchwork/patch/19931/) and I am moving the new sample files in the right order. Thanks, Pablo
[dpdk-dev] [PATCH] app/testpmd: fix memory leak
Free memory when port flow entry creation fails.
Coverity issue: 139600
Fixes: 938a184a1870 ("app/testpmd: implement basic support for flow API")
Signed-off-by: Pablo de Lara
---
app/test-pmd/config.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 5834498..5823100 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -954,6 +954,8 @@ port_flow_new(const struct rte_flow_attr *attr,
goto store;
}
notsup:
+ if (pf)
+ free(pf);
rte_errno = err;
return NULL;
}
--
2.7.4
[dpdk-dev] [PATCH] crypto/aesni_mb: add missing digest length
AESNI MB now supports authentication only operations,
but the array containing all the possible digest lengths
was not updated to reflect the new algorithm NULL_HASH,
causing an "Out-of-bounds access".
Coverity issue: 140977
Fixes: 8772c3f713e2 ("crypto/aesni_mb: add single operation functionality")
Signed-off-by: Pablo de Lara
---
drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
index 5f125b2..eb4b2ad 100644
--- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
+++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
@@ -88,6 +88,7 @@ static const unsigned auth_truncated_digest_byte_lengths[] = {
[SHA_384] = 24,
[SHA_512] = 32,
[AES_XCBC] = 12,
+ [NULL_HASH] = 0
};
/**
@@ -111,6 +112,7 @@ static const unsigned auth_digest_byte_lengths[] = {
[SHA_384] = 48,
[SHA_512] = 64,
[AES_XCBC] = 16,
+ [NULL_HASH] = 0
};
/**
--
2.7.4
Re: [dpdk-dev] [PATCH] crypto/aesni_mb: add missing digest length
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Friday, January 27, 2017 1:16 PM
> To: adrien.mazarg...@6wind.com; Wu, Jingjing
> Cc: dev@dpdk.org; De Lara Guarch, Pablo
> Subject: [PATCH] crypto/aesni_mb: add missing digest length
>
> AESNI MB now supports authentication only operations,
> but the array containing all the possible digest lengths
> was not updated to reflect the new algorithm NULL_HASH,
> causing an "Out-of-bounds access".
>
> Coverity issue: 140977
> Fixes: 8772c3f713e2 ("crypto/aesni_mb: add single operation
> functionality")
>
> Signed-off-by: Pablo de Lara
> ---
> drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
> b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
> index 5f125b2..eb4b2ad 100644
> --- a/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
> +++ b/drivers/crypto/aesni_mb/rte_aesni_mb_pmd_private.h
> @@ -88,6 +88,7 @@ static const unsigned
> auth_truncated_digest_byte_lengths[] = {
> [SHA_384] = 24,
> [SHA_512] = 32,
> [AES_XCBC] = 12,
> + [NULL_HASH] = 0
> };
>
> /**
> @@ -111,6 +112,7 @@ static const unsigned auth_digest_byte_lengths[] =
> {
> [SHA_384] = 48,
> [SHA_512] = 64,
> [AES_XCBC] = 16,
> + [NULL_HASH] = 0
> };
>
> /**
> --
> 2.7.4
Wrong maintainer, Sending to right one now. Sorry about that.
Re: [dpdk-dev] [dpdk-stable] [PATCH v6 1/3] net/i40e: fix segmentation fault in close
On 1/27/2017 10:22 AM, Bernard Iremonger wrote:
> Change the order of releasing the vsi's.
> Release the vmdq vsi's first, then release the main vsi.
>
> Fixes: 4861cde46116 ("i40e: new poll mode driver")
>
> CC: sta...@dpdk.org
>
> Signed-off-by: Bernard Iremonger
> Acked-by: Jingjing Wu
Fixes: 3cb446b4aeb2 ("i40e: free vmdq vsi when closing")
Cc: sta...@dpdk.org
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/ixgbe: fix API comments for doxygen
On 1/27/2017 12:27 PM, Ferruh Yigit wrote:
> Fixes: 57aa1fd284d5 ("net/ixgbe: move set VF functions from the ethdev")
>
> Signed-off-by: Ferruh Yigit
Applied to dpdk-next-net/master, thanks.
Re: [dpdk-dev] [PATCH] net/i40e: fix API comments for doxygen
On 1/27/2017 12:27 PM, Ferruh Yigit wrote:
> Fixes: a541407fe4bc ("net/i40e: set VF MAC anti-spoofing from PF")
> Fixes: 4cbc41efcbb2 ("net/i40e: set VF VLAN anti-spoofing from PF")
> Fixes: c0ec14757c5f ("net/i40e: set VF unicast promiscuous mode from PF")
> Fixes: ae57070ca8b7 ("net/i40e: set VF multicast promiscuous mode from PF")
> Fixes: 83bb95e3fefc ("net/i40e: set VF VLAN insertion from PF")
> Fixes: 61fff9b4c68b ("net/i40e: set VF broadcast mode from PF")
> Fixes: c33abbc1440e ("net/i40e: set VF VLAN tag from PF")
>
> Signed-off-by: Ferruh Yigit
Applied to dpdk-next-net/master, thanks.
[dpdk-dev] [PATCH] efd: fix compilation by removing dep to libmath
When we compile the dpdk with: CONFIG_RTE_LIBRTE_EFD=y CONFIG_RTE_LIBRTE_NFP_PMD=n CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD=n CONFIG_RTE_LIBRTE_SCHED=n CONFIG_RTE_LIBRTE_METER=n The linker gives the following error: lib/librte_efd.a(rte_efd.o): In function `rte_efd_create': lib/librte_efd/rte_efd.c:560: undefined reference to `log2' collect2: error: ld returned 1 exit status This is because the '-lm' is missing in mk/rte.app.mk. An alternative, which is proposed by this patch, is to use the compiler builtin rte_bsf32() to process log2 instead of the libmath log2() that requires to include math.h and link with -lm. Signed-off-by: Olivier Matz --- lib/librte_efd/Makefile | 2 -- lib/librte_efd/rte_efd.c | 3 +-- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/lib/librte_efd/Makefile b/lib/librte_efd/Makefile index 8848c58..a442c62 100644 --- a/lib/librte_efd/Makefile +++ b/lib/librte_efd/Makefile @@ -34,8 +34,6 @@ include $(RTE_SDK)/mk/rte.vars.mk # library name LIB = librte_efd.a -LDLIBS += -lm - CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) -I$(SRCDIR) diff --git a/lib/librte_efd/rte_efd.c b/lib/librte_efd/rte_efd.c index 68e6dab..f601d62 100644 --- a/lib/librte_efd/rte_efd.c +++ b/lib/librte_efd/rte_efd.c @@ -36,7 +36,6 @@ #include #include #include -#include #include #include @@ -557,7 +556,7 @@ rte_efd_create(const char *name, uint32_t max_num_rules, uint32_t key_len, num_chunks = rte_align32pow2((max_num_rules / EFD_TARGET_CHUNK_NUM_RULES) + 1); - num_chunks_shift = log2(num_chunks); + num_chunks_shift = rte_bsf32(num_chunks); rte_rwlock_write_lock(RTE_EAL_TAILQ_RWLOCK); -- 2.8.1
Re: [dpdk-dev] [PATCH] efd: fix compilation by removing dep to libmath
> -Original Message- > From: Olivier Matz [mailto:olivier.m...@6wind.com] > Sent: Friday, January 27, 2017 2:23 PM > To: dev@dpdk.org; Marohn, Byron; De Lara Guarch, Pablo > Subject: [PATCH] efd: fix compilation by removing dep to libmath > > When we compile the dpdk with: > CONFIG_RTE_LIBRTE_EFD=y > CONFIG_RTE_LIBRTE_NFP_PMD=n > CONFIG_RTE_LIBRTE_THUNDERX_NICVF_PMD=n > CONFIG_RTE_LIBRTE_SCHED=n > CONFIG_RTE_LIBRTE_METER=n > > The linker gives the following error: > lib/librte_efd.a(rte_efd.o): In function `rte_efd_create': > lib/librte_efd/rte_efd.c:560: undefined reference to `log2' > collect2: error: ld returned 1 exit status > > This is because the '-lm' is missing in mk/rte.app.mk. > > An alternative, which is proposed by this patch, is to use the compiler > builtin rte_bsf32() to process log2 instead of the libmath log2() that > requires to include math.h and link with -lm. > > Signed-off-by: Olivier Matz Acked-by: Pablo de Lara Nice catch, thanks!
[dpdk-dev] [PATCH v2] app/testpmd: fix memory leak
Free memory when port flow entry creation fails.
Coverity issue: 139600
Fixes: 938a184a1870 ("app/testpmd: implement basic support for flow API")
Signed-off-by: Pablo de Lara
---
Changes in v2:
- Removed unnecessary conditional
app/test-pmd/config.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test-pmd/config.c b/app/test-pmd/config.c
index 5834498..467932f 100644
--- a/app/test-pmd/config.c
+++ b/app/test-pmd/config.c
@@ -954,6 +954,7 @@ port_flow_new(const struct rte_flow_attr *attr,
goto store;
}
notsup:
+ free(pf);
rte_errno = err;
return NULL;
}
--
2.7.4
[dpdk-dev] [PATCH 04/25] eal: do not panic on failed hugepage query
If we fail to acquire hugepage information, simply signal an error to
the application. This clears the run_once counter, allowing the user or
application to take a corrective action and retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index ea7a4e4..f139558 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -780,8 +780,12 @@ rte_eal_init(int argc, char **argv)
if (internal_config.no_hugetlbfs == 0 &&
internal_config.process_type != RTE_PROC_SECONDARY &&
internal_config.xen_dom0_support == 0 &&
- eal_hugepage_info_init() < 0)
- rte_panic("Cannot get hugepage information\n");
+ eal_hugepage_info_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot get hugepage information\n");
+ rte_errno = EACCES;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
if (internal_config.memory == 0 && internal_config.force_sockets == 0) {
if (internal_config.no_hugetlbfs)
--
2.7.4
[dpdk-dev] [PATCH 00/24] linux/eal: Remove most causes of panic on init
In many cases, it's enough to simply let the application know that the call to initialize DPDK has failed. A complete halt can then be decided by the application based on error returned (and the app could even attempt a possible re-attempt after some corrective action by the user or application). Aaron Conole (24): eal: CPU init will no longer panic eal: return error instead of panic for cpu init eal: No panic on hugepages info init eal: do not panic on failed hugepage query eal: failure to parse args returns error eal-common: introduce a way to query cpu support eal: Signal error when CPU isn't supported eal: do not panic on memzone initialization fails eal: set errno when exiting for already called eal: Do not panic on log failures eal: Do not panic on pci-probe eal: do not panic on vfio failure eal: do not panic on memory init eal: do not panic on tailq init eal: do not panic on alarm init eal: convert timer_init not to call panic eal: change the private pipe call to reflect errno eal: Do not panic on interrupt thread init eal: do not error if plugins fail to init eal_pci: Continue probing even on failures eal: do not panic on failed PCI probe eal_common_dev: continue initializing vdevs eal: do not panic (or abort) if vdev init fails eal: do not panic when bus probe fails lib/librte_eal/common/eal_common_cpuflags.c| 13 ++- lib/librte_eal/common/eal_common_dev.c | 5 +- lib/librte_eal/common/eal_common_lcore.c | 7 +- lib/librte_eal/common/eal_common_pci.c | 15 ++- lib/librte_eal/common/eal_common_tailqs.c | 4 +- .../common/include/generic/rte_cpuflags.h | 9 ++ lib/librte_eal/linuxapp/eal/eal.c | 121 +++-- lib/librte_eal/linuxapp/eal/eal_hugepage_info.c| 6 +- lib/librte_eal/linuxapp/eal/eal_interrupts.c | 5 +- 9 files changed, 135 insertions(+), 50 deletions(-) -- 2.7.4
[dpdk-dev] [PATCH 02/25] eal: return error instead of panic for cpu init
There may be no way to gracefully recover, but the application
should be notified that a failure happened, rather than completely
aborting. This allows the user to proceed with a "slow-path" type
solution.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index bf6b818..ea7a4e4 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -767,8 +767,11 @@ rte_eal_init(int argc, char **argv)
/* set log level as early as possible */
rte_set_log_level(internal_config.log_level);
- if (rte_eal_cpu_init() < 0)
- rte_panic("Cannot detect lcores\n");
+ if (rte_eal_cpu_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot detect lcores\n");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
fctret = eal_parse_args(argc, argv);
if (fctret < 0)
--
2.7.4
[dpdk-dev] [PATCH 05/25] eal: failure to parse args returns error
It's possible that the application could take a corrective action here,
and either prompt the user for different arguments, or at least perform
a better logging. Exiting this early prevents any useful information
gathering from the application layer.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index f139558..413be16 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -774,8 +774,12 @@ rte_eal_init(int argc, char **argv)
}
fctret = eal_parse_args(argc, argv);
- if (fctret < 0)
- exit(1);
+ if (fctret < 0) {
+ RTE_LOG (ERR, EAL, "Invalid 'command line' arguments\n");
+ rte_errno = EINVAL;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
if (internal_config.no_hugetlbfs == 0 &&
internal_config.process_type != RTE_PROC_SECONDARY &&
--
2.7.4
[dpdk-dev] [PATCH 06/25] eal-common: introduce a way to query cpu support
This adds a new API to check for the eal cpu versions.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_cpuflags.c | 13 +++--
lib/librte_eal/common/include/generic/rte_cpuflags.h | 9 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_cpuflags.c
b/lib/librte_eal/common/eal_common_cpuflags.c
index b5f76f7..2c2127b 100644
--- a/lib/librte_eal/common/eal_common_cpuflags.c
+++ b/lib/librte_eal/common/eal_common_cpuflags.c
@@ -43,6 +43,13 @@
void
rte_cpu_check_supported(void)
{
+ if (!rte_cpu_is_supported())
+ exit(1);
+}
+
+bool
+rte_cpu_is_supported(void)
+{
/* This is generated at compile-time by the build system */
static const enum rte_cpu_flag_t compile_time_flags[] = {
RTE_COMPILE_TIME_CPUFLAGS
@@ -57,14 +64,16 @@ rte_cpu_check_supported(void)
fprintf(stderr,
"ERROR: CPU feature flag lookup failed with
error %d\n",
ret);
- exit(1);
+ return false;
}
if (!ret) {
fprintf(stderr,
"ERROR: This system does not support \"%s\".\n"
"Please check that RTE_MACHINE is set
correctly.\n",
rte_cpu_get_flag_name(compile_time_flags[i]));
- exit(1);
+ return false;
}
}
+
+ return true;
}
diff --git a/lib/librte_eal/common/include/generic/rte_cpuflags.h
b/lib/librte_eal/common/include/generic/rte_cpuflags.h
index 71321f3..e4342ad 100644
--- a/lib/librte_eal/common/include/generic/rte_cpuflags.h
+++ b/lib/librte_eal/common/include/generic/rte_cpuflags.h
@@ -40,6 +40,7 @@
*/
#include
+#include
/**
* Enumeration of all CPU features supported
@@ -82,4 +83,12 @@ rte_cpu_get_flag_enabled(enum rte_cpu_flag_t feature);
void
rte_cpu_check_supported(void);
+/**
+ * This function checks that the currently used CPU supports the CPU features
+ * that were specified at compile time. It is called automatically within the
+ * EAL, so does not need to be used by applications. This version returns a
+ * result so that decisions may be made (for instance, graceful shutdowns).
+ */
+bool
+rte_cpu_is_supported(void);
#endif /* _RTE_CPUFLAGS_H_ */
--
2.7.4
[dpdk-dev] [PATCH 08/25] eal: do not panic on memzone initialization fails
When memzone initialization fails, report the error to the calling
application rather than panic(). Without a good way of detaching /
releasing hugepages, at this point the application will have to restart.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index cd976f5..cc1bcb5 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -831,8 +831,11 @@ rte_eal_init(int argc, char **argv)
/* the directories are locked during eal_hugepage_info_init */
eal_hugedirs_unlock();
- if (rte_eal_memzone_init() < 0)
- rte_panic("Cannot init memzone\n");
+ if (rte_eal_memzone_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init memzone\n");
+ rte_errno = ENODEV;
+ return -1;
+ }
if (rte_eal_tailqs_init() < 0)
rte_panic("Cannot init tail queues for objects\n");
--
2.7.4
[dpdk-dev] [PATCH 07/25] eal: Signal error when CPU isn't supported
It's now possible to gracefully exit the application, or for
applications which support non-dpdk datapaths working in concert with
DPDK datapaths, there no longer is the possibility of exiting for
unsupported CPUs.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 413be16..cd976f5 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -752,7 +752,10 @@ rte_eal_init(int argc, char **argv)
char thread_name[RTE_MAX_THREAD_NAME_LEN];
/* checks if the machine is adequate */
- rte_cpu_check_supported();
+ if (!rte_cpu_is_supported()) {
+ rte_errno = ENOTSUP;
+ return -1;
+ }
if (!rte_atomic32_test_and_set(&run_once))
return -1;
--
2.7.4
[dpdk-dev] [PATCH 10/25] eal: Do not panic on log failures
When log initialization fails, it's generally because the fopencookie
failed. While this is rare in practice, it could happen, and it is
likely because of memory pressure. So, flag the error, and allow the
user to retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index f5f6629..b774e41 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -816,8 +816,12 @@ rte_eal_init(int argc, char **argv)
rte_config_init();
- if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0)
- rte_panic("Cannot init logs\n");
+ if (rte_eal_log_init(logid, internal_config.syslog_facility) < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init logging\n");
+ rte_errno = EIO;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
if (rte_eal_pci_init() < 0)
rte_panic("Cannot init PCI\n");
--
2.7.4
[dpdk-dev] [PATCH 13/25] eal: do not panic on memory init
This can only happen when access to hugepages (either as primary or
secondary process) fails (and that is usually permissions). Since the
manner of failure is not reversible, we cannot allow retry.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index cfeefad..d20ac37 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -839,8 +839,11 @@ rte_eal_init(int argc, char **argv)
}
#endif
- if (rte_eal_memory_init() < 0)
- rte_panic("Cannot init memory\n");
+ if (rte_eal_memory_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init memory\n");
+ rte_errno = EACCES;
+ return -1;
+ }
/* the directories are locked during eal_hugepage_info_init */
eal_hugedirs_unlock();
--
2.7.4
[dpdk-dev] [PATCH 12/25] eal: do not panic on vfio failure
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index bea9a23..cfeefad 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -831,8 +831,12 @@ rte_eal_init(int argc, char **argv)
}
#ifdef VFIO_PRESENT
- if (rte_eal_vfio_setup() < 0)
- rte_panic("Cannot init VFIO\n");
+ if (rte_eal_vfio_setup() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init VFIO\n");
+ rte_errno = EAGAIN;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
#endif
if (rte_eal_memory_init() < 0)
--
2.7.4
[dpdk-dev] [PATCH 14/25] eal: do not panic on tailq init
There are some theoretical racy conditions in the system that _could_
cause early tailq init to fail; however, no need to panic the
application. While it can't continue using DPDK, it could make better
alerts to the user.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_tailqs.c | 4 ++--
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_tailqs.c
b/lib/librte_eal/common/eal_common_tailqs.c
index bb08ec8..b856ec9 100644
--- a/lib/librte_eal/common/eal_common_tailqs.c
+++ b/lib/librte_eal/common/eal_common_tailqs.c
@@ -188,8 +188,8 @@ rte_eal_tailqs_init(void)
if (t->head == NULL) {
RTE_LOG(ERR, EAL,
"Cannot initialize tailq: %s\n", t->name);
- /* no need to TAILQ_REMOVE, we are going to panic in
-* rte_eal_init() */
+ /* no need to TAILQ_REMOVE, we are going to disallow
re-attemtps
+* for rte_eal_init(). */
goto fail;
}
}
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index d20ac37..b16313c 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -854,8 +854,11 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (rte_eal_tailqs_init() < 0)
- rte_panic("Cannot init tail queues for objects\n");
+ if (rte_eal_tailqs_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init tail queues for objects\n");
+ errno = ENOTSUP;
+ return -1;
+ }
if (rte_eal_alarm_init() < 0)
rte_panic("Cannot init interrupt-handling thread\n");
--
2.7.4
[dpdk-dev] [PATCH 15/25] eal: do not panic on alarm init
rte_eal_alarm_init() call uses the linux timerfd framework to create a
poll()-able timer using standard posix file operations. This could fail
for a few reasons given in the man-pages, but many could be
corrected by the user application. No need to panic.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index b16313c..122d9c2 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -61,6 +61,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -860,8 +861,12 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (rte_eal_alarm_init() < 0)
- rte_panic("Cannot init interrupt-handling thread\n");
+ if (rte_eal_alarm_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init interrupt-handling thread\n");
+ /* rte_eal_alarm_init sets rte_errno on failure. */
+ errno = rte_errno;
+ return -1;
+ }
if (rte_eal_timer_init() < 0)
rte_panic("Cannot init HPET or TSC timers\n");
--
2.7.4
[dpdk-dev] [PATCH 16/25] eal: convert timer_init not to call panic
After code inspection, there is no way for eal_timer_init() to fail. It
simply returns 0 in all cases. As such, this test could either go-away
or stay here as 'future-proofing'.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 122d9c2..bd1863d 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -868,8 +868,11 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (rte_eal_timer_init() < 0)
- rte_panic("Cannot init HPET or TSC timers\n");
+ if (rte_eal_timer_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init HPET or TSC timers\n");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
eal_check_mem_on_local_socket();
--
2.7.4
[dpdk-dev] [PATCH 17/25] eal: change the private pipe call to reflect errno
There could be some confusion as to why the call failed - this change
will always reflect the value of the error in rte_error.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal_interrupts.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
index b5b3f2b..b1a287c 100644
--- a/lib/librte_eal/linuxapp/eal/eal_interrupts.c
+++ b/lib/librte_eal/linuxapp/eal/eal_interrupts.c
@@ -896,13 +896,16 @@ rte_eal_intr_init(void)
* create a pipe which will be waited by epoll and notified to
* rebuild the wait list of epoll.
*/
- if (pipe(intr_pipe.pipefd) < 0)
+ if (pipe(intr_pipe.pipefd) < 0) {
+ rte_errno = errno;
return -1;
+ }
/* create the host thread to wait/handle the interrupt */
ret = pthread_create(&intr_thread, NULL,
eal_intr_thread_main, NULL);
if (ret != 0) {
+ rte_errno = ret;
RTE_LOG(ERR, EAL,
"Failed to create thread for interrupt handling\n");
} else {
--
2.7.4
[dpdk-dev] [PATCH 18/25] eal: Do not panic on interrupt thread init
When initializing the interrupt thread, there are a number of possible
reasons for failure - some of which are correctable by the application.
Do not panic() needlessly, and give the application a change to reflect
this information to the user.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index bd1863d..948393e 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -887,8 +887,11 @@ rte_eal_init(int argc, char **argv)
rte_config.master_lcore, (int)thread_id, cpuset,
ret == 0 ? "" : "...");
- if (rte_eal_intr_init() < 0)
- rte_panic("Cannot init interrupt-handling thread\n");
+ if (rte_eal_intr_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init interrupt-handling thread\n");
+ errno = rte_errno;
+ return -1;
+ }
if (rte_bus_scan())
rte_panic("Cannot scan the buses for devices\n");
--
2.7.4
[dpdk-dev] [PATCH 19/25] eal: do not error if plugins fail to init
Plugins are useful and important. However, it seems crazy to abort
everything just because they don't initialize properly.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 948393e..2fdafaa 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -876,8 +876,9 @@ rte_eal_init(int argc, char **argv)
eal_check_mem_on_local_socket();
- if (eal_plugins_init() < 0)
- rte_panic("Cannot init plugins\n");
+ if (eal_plugins_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init plugins\n");
+ }
eal_thread_init_master(rte_config.master_lcore);
--
2.7.4
[dpdk-dev] [PATCH 21/25] eal: do not panic on failed PCI probe
It may even be possible to simply log the error and continue on letting
the user check the logs and restart the application when things are failed.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index 2fdafaa..e77d7f7 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -938,8 +938,11 @@ rte_eal_init(int argc, char **argv)
rte_panic("Cannot probe devices\n");
/* Probe & Initialize PCI devices */
- if (rte_eal_pci_probe())
- rte_panic("Cannot probe PCI\n");
+ if (rte_eal_pci_probe()) {
+ RTE_LOG (ERR, EAL, "Cannot probe PCI\n");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
if (rte_eal_dev_init() < 0)
rte_panic("Cannot init pmd devices\n");
--
2.7.4
[dpdk-dev] [PATCH 20/25] eal_pci: Continue probing even on failures
Some devices may be inaccessible for a variety of reasons, or the
PCI-bus may be unavailable causing the whole thing to fail. Still,
better to continue attempts at probes.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_pci.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_pci.c
b/lib/librte_eal/common/eal_common_pci.c
index 72547bd..752c278 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -69,6 +69,7 @@
#include
#include
+#include
#include
#include
#include
@@ -416,6 +417,7 @@ rte_eal_pci_probe(void)
struct rte_pci_device *dev = NULL;
struct rte_devargs *devargs;
int probe_all = 0;
+ int ret_1 = 0;
int ret = 0;
if (rte_eal_devargs_type_count(RTE_DEVTYPE_WHITELISTED_PCI) == 0)
@@ -430,17 +432,20 @@ rte_eal_pci_probe(void)
/* probe all or only whitelisted devices */
if (probe_all)
- ret = pci_probe_all_drivers(dev);
+ ret_1 = pci_probe_all_drivers(dev);
else if (devargs != NULL &&
devargs->type == RTE_DEVTYPE_WHITELISTED_PCI)
- ret = pci_probe_all_drivers(dev);
- if (ret < 0)
- rte_exit(EXIT_FAILURE, "Requested device " PCI_PRI_FMT
+ ret_1 = pci_probe_all_drivers(dev);
+ if (ret_1 < 0) {
+ RTE_LOG (ERR, EAL, "Requested device " PCI_PRI_FMT
" cannot be used\n", dev->addr.domain,
dev->addr.bus,
dev->addr.devid, dev->addr.function);
+ rte_errno = errno;
+ ret = 1;
+ }
}
- return 0;
+ return -ret;
}
/* dump one device */
--
2.7.4
[dpdk-dev] [PATCH 24/25] eal: do not panic when bus probe fails
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index ecb6ac8..2783755 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -934,8 +934,11 @@ rte_eal_init(int argc, char **argv)
rte_eal_mp_wait_lcore();
/* Probe all the buses and devices/drivers on them */
- if (rte_bus_probe())
- rte_panic("Cannot probe devices\n");
+ if (rte_bus_probe()) {
+ RTE_LOG (ERR, EAL, "Cannot probe devices\n");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
/* Probe & Initialize PCI devices */
if (rte_eal_pci_probe()) {
--
2.7.4
[dpdk-dev] [PATCH 22/25] eal_common_dev: continue initializing vdevs
Even if one vdev should fail, there's no need to prevent further
processing. Log the error, and reflect it to the higher levels to
decide.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_dev.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_dev.c
b/lib/librte_eal/common/eal_common_dev.c
index 4f3b493..9889997 100644
--- a/lib/librte_eal/common/eal_common_dev.c
+++ b/lib/librte_eal/common/eal_common_dev.c
@@ -80,6 +80,7 @@ int
rte_eal_dev_init(void)
{
struct rte_devargs *devargs;
+ int ret = 0;
/*
* Note that the dev_driver_list is populated here
@@ -97,11 +98,11 @@ rte_eal_dev_init(void)
devargs->args)) {
RTE_LOG(ERR, EAL, "failed to initialize %s device\n",
devargs->virt.drv_name);
- return -1;
+ ret = -1;
}
}
- return 0;
+ return ret;
}
int rte_eal_dev_attach(const char *name, const char *devargs)
--
2.7.4
[dpdk-dev] [PATCH 23/25] eal: do not panic (or abort) if vdev init fails
Seems like it's possible to continue. At least, the error is reflected
properly in the logs. A user could then go and correct or investigate
the situation.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index e77d7f7..ecb6ac8 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -945,7 +945,7 @@ rte_eal_init(int argc, char **argv)
}
if (rte_eal_dev_init() < 0)
- rte_panic("Cannot init pmd devices\n");
+ RTE_LOG (ERR, EAL, "Cannot init pmd devices\n");
rte_eal_mcfg_complete();
--
2.7.4
[dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes
The rte_eal_init function will now pass failure reason hints to the application. To help app developers deciper this, add some brief information about what the codes are indicating. Signed-off-by: Aaron Conole --- lib/librte_eal/common/include/rte_eal.h | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/lib/librte_eal/common/include/rte_eal.h b/lib/librte_eal/common/include/rte_eal.h index 03fee50..46e427f 100644 --- a/lib/librte_eal/common/include/rte_eal.h +++ b/lib/librte_eal/common/include/rte_eal.h @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void); * function call and should not be further interpreted by the * application. The EAL does not take any ownership of the memory used * for either the argv array, or its members. - * - On failure, a negative error value. + * - On failure, -1 and rte_errno is set to a value indicating the cause + * for failure. + * + * The error codes returned via rte_errno: + * EACCES indicates a permissions issue. + * + * EAGAIN indicates either a bus or system resource was not available, + *try again. + * + * EALREADY indicates that the rte_eal_init function has already been + * called, and cannot be called again. + * + * EINVAL indicates invalid parameters were passed as argv/argc. + * + * EIO indicates failure to setup the logging handlers. This is usually + * caused by an out-of-memory condition. + * + * ENODEV indicates memory setup issues. + * + * ENOTSUP indicates that the EAL cannot initialize on this system. + * + * EUNATCH indicates that the PCI bus is either not present, or is not + * readable by the eal. */ int rte_eal_init(int argc, char **argv); -- 2.7.4
[dpdk-dev] [PATCH 01/25] eal: CPU init will no longer panic
After this change, the EAL CPU NUMA node resolution step can no longer
emit an rte_panic. This aligns with the code in rte_eal_init, which
expects failures to return an error code.
Signed-off-by: Aaron Conole
---
lib/librte_eal/common/eal_common_lcore.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/librte_eal/common/eal_common_lcore.c
b/lib/librte_eal/common/eal_common_lcore.c
index 2cd4132..84fa0cb 100644
--- a/lib/librte_eal/common/eal_common_lcore.c
+++ b/lib/librte_eal/common/eal_common_lcore.c
@@ -83,16 +83,17 @@ rte_eal_cpu_init(void)
config->lcore_role[lcore_id] = ROLE_RTE;
lcore_config[lcore_id].core_id = eal_cpu_core_id(lcore_id);
lcore_config[lcore_id].socket_id = eal_cpu_socket_id(lcore_id);
- if (lcore_config[lcore_id].socket_id >= RTE_MAX_NUMA_NODES)
+ if (lcore_config[lcore_id].socket_id >= RTE_MAX_NUMA_NODES) {
#ifdef RTE_EAL_ALLOW_INV_SOCKET_ID
lcore_config[lcore_id].socket_id = 0;
#else
- rte_panic("Socket ID (%u) is greater than "
+ RTE_LOG(ERR, EAL, "Socket ID (%u) is greater than "
"RTE_MAX_NUMA_NODES (%d)\n",
lcore_config[lcore_id].socket_id,
RTE_MAX_NUMA_NODES);
+ return -1;
#endif
-
+ }
RTE_LOG(DEBUG, EAL, "Detected lcore %u as "
"core %u on socket %u\n",
lcore_id, lcore_config[lcore_id].core_id,
--
2.7.4
[dpdk-dev] [PATCH 03/25] eal: No panic on hugepages info init
When attempting to scan hugepages, signal to the eal.c that an error has
occured, rather than performing a panic.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal_hugepage_info.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
index 18858e2..4d47eaf 100644
--- a/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
+++ b/lib/librte_eal/linuxapp/eal/eal_hugepage_info.c
@@ -283,9 +283,11 @@ eal_hugepage_info_init(void)
struct dirent *dirent;
dir = opendir(sys_dir_path);
- if (dir == NULL)
- rte_panic("Cannot open directory %s to read system hugepage "
+ if (dir == NULL) {
+ RTE_LOG(ERR, EAL, "Cannot open directory %s to read system
hugepage "
"info\n", sys_dir_path);
+ return -1;
+ }
for (dirent = readdir(dir); dirent != NULL; dirent = readdir(dir)) {
struct hugepage_info *hpi;
--
2.7.4
[dpdk-dev] [PATCH 09/25] eal: set errno when exiting for already called
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index cc1bcb5..f5f6629 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -757,8 +757,10 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (!rte_atomic32_test_and_set(&run_once))
+ if (!rte_atomic32_test_and_set(&run_once)) {
+ rte_errno = EALREADY;
return -1;
+ }
logid = strrchr(argv[0], '/');
logid = strdup(logid ? logid + 1: argv[0]);
--
2.7.4
[dpdk-dev] [PATCH 11/25] eal: Do not panic on pci-probe
This will usually be an issue because of permissions. However, it could
also be caused by OOM. In either case, errno will contain the
underlying cause. It is safe to re-init the system here, so allow the
application to take corrective action and reinit.
Signed-off-by: Aaron Conole
---
lib/librte_eal/linuxapp/eal/eal.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
b/lib/librte_eal/linuxapp/eal/eal.c
index b774e41..bea9a23 100644
--- a/lib/librte_eal/linuxapp/eal/eal.c
+++ b/lib/librte_eal/linuxapp/eal/eal.c
@@ -823,8 +823,12 @@ rte_eal_init(int argc, char **argv)
return -1;
}
- if (rte_eal_pci_init() < 0)
- rte_panic("Cannot init PCI\n");
+ if (rte_eal_pci_init() < 0) {
+ RTE_LOG (ERR, EAL, "Cannot init PCI\n");
+ rte_errno = EUNATCH;
+ rte_atomic32_clear(&run_once);
+ return -1;
+ }
#ifdef VFIO_PRESENT
if (rte_eal_vfio_setup() < 0)
--
2.7.4
[dpdk-dev] [PATCH 1/2] net/mlx5: fix VLAN validation
TCI field is read from the wrong place due to an invalid cast. Moreover
there is no need to limit matching to VID since PCP and DEI bits can be
matched as well.
Fixes: 12475fb203ad ("net/mlx5: support VLAN flow item")
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5_flow.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index 7b97a61..d805c0a 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -410,17 +410,6 @@ priv_flow_validate(struct priv *priv,
if (items->type == RTE_FLOW_ITEM_TYPE_VOID)
continue;
- /* Handle special situation for VLAN. */
- if (items->type == RTE_FLOW_ITEM_TYPE_VLAN) {
- if (((const struct rte_flow_item_vlan *)items)->tci >
- ETHER_MAX_VLAN_ID) {
- rte_flow_error_set(error, ENOTSUP,
- RTE_FLOW_ERROR_TYPE_ITEM,
- items,
- "wrong VLAN id value");
- return -rte_errno;
- }
- }
for (i = 0;
cur_item->items &&
cur_item->items[i] != RTE_FLOW_ITEM_TYPE_END;
--
2.1.4
[dpdk-dev] [PATCH 2/2] net/mlx5: fix validation
Size of the mask is wrongly computed and make the validation process only
verify the first 4 bytes of the layer.
Fixes: 2097d0d1e2cc ("net/mlx5: support basic flow items and actions")
Signed-off-by: Nelio Laranjeiro
---
drivers/net/mlx5/mlx5_flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mlx5/mlx5_flow.c b/drivers/net/mlx5/mlx5_flow.c
index d805c0a..42a12e8 100644
--- a/drivers/net/mlx5/mlx5_flow.c
+++ b/drivers/net/mlx5/mlx5_flow.c
@@ -424,7 +424,7 @@ priv_flow_validate(struct priv *priv,
cur_item = token;
err = mlx5_flow_item_validate(items,
(const uint8_t *)cur_item->mask,
- sizeof(cur_item->mask_sz));
+ cur_item->mask_sz);
if (err)
goto exit_item_not_supported;
if (flow->ibv_attr && cur_item->convert) {
--
2.1.4
Re: [dpdk-dev] [PATCH 00/24] linux/eal: Remove most causes of panic on init
Aaron Conole writes: > In many cases, it's enough to simply let the application know that the > call to initialize DPDK has failed. A complete halt can then be > decided by the application based on error returned (and the app could > even attempt a possible re-attempt after some corrective action by the > user or application). > I got some emails about checkpatch issues for style. I guess I have none :( I'll fix these all up and resubmit a v2 next week.
Re: [dpdk-dev] [PATCH] doc: update examples list for API
2017-01-27 11:55, Ferruh Yigit: > These files are linked to API documentation as usage samples, added > missing examples files and sorted list alphabetically. > > Signed-off-by: Ferruh Yigit Why not replacing this list with a "find examples -type f" in mk/rte.sdkdoc.mk?
Re: [dpdk-dev] [PATCH] doc: fix incomplete crypto dev matrices
> -Original Message-
> From: De Lara Guarch, Pablo
> Sent: Wednesday, January 18, 2017 5:36 PM
> To: dev@dpdk.org
> Cc: De Lara Guarch, Pablo
> Subject: [PATCH] doc: fix incomplete crypto dev matrices
>
> When ZUC PMD was added, it was not added in the
> Crypto Device Supported Functionality Matrices.
> This commit adds a column in all the matrices, plus
> the ZUC EEA3/EIA3 algorithms.
>
> Fixes: cf7685d68f00 ("crypto/zuc: add driver for ZUC library")
>
> Signed-off-by: Pablo de Lara
Applied to dpdk-next-crypto.
Pablo
Re: [dpdk-dev] [PATCH 07/25] eal: Signal error when CPU isn't supported
On Fri, 27 Jan 2017 09:56:45 -0500
Aaron Conole wrote:
> It's now possible to gracefully exit the application, or for
> applications which support non-dpdk datapaths working in concert with
> DPDK datapaths, there no longer is the possibility of exiting for
> unsupported CPUs.
>
> Signed-off-by: Aaron Conole
> ---
> lib/librte_eal/linuxapp/eal/eal.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> b/lib/librte_eal/linuxapp/eal/eal.c
> index 413be16..cd976f5 100644
> --- a/lib/librte_eal/linuxapp/eal/eal.c
> +++ b/lib/librte_eal/linuxapp/eal/eal.c
> @@ -752,7 +752,10 @@ rte_eal_init(int argc, char **argv)
> char thread_name[RTE_MAX_THREAD_NAME_LEN];
>
> /* checks if the machine is adequate */
> - rte_cpu_check_supported();
> + if (!rte_cpu_is_supported()) {
> + rte_errno = ENOTSUP;
> + return -1;
> + }
>
I like not having DPDK applications panic.
My concern is that naive user will not know to check rte_errno. Why not put
a high severity error out as well. If logging is not up just use stderr.
Re: [dpdk-dev] [PATCH 14/25] eal: do not panic on tailq init
On Fri, 27 Jan 2017 09:56:52 -0500 Aaron Conole wrote: > + /* no need to TAILQ_REMOVE, we are going to disallow > re-attemtps > + * for rte_eal_init(). */ Please put multi-line comments in form: /* * this is a long comment * because there really is lots to say */ In many cases, having shorter comment is the best way to handle these. Often developer writes long comment for themselves because what ever problem they saw was urgent. Then comment becomes irrelevant later. /* TAILQ_REMOVE not needed, error is already fatal */
Re: [dpdk-dev] [PATCH 15/25] eal: do not panic on alarm init
On Fri, 27 Jan 2017 09:56:53 -0500
Aaron Conole wrote:
> + if (rte_eal_alarm_init() < 0) {
> + RTE_LOG (ERR, EAL, "Cannot init interrupt-handling thread\n");
> + /* rte_eal_alarm_init sets rte_errno on failure. */
> + errno = rte_errno;
Hmm. DPDK in general does not reset errno but instead uses error code
directly on return (best) or in some cases rte_errno
Re: [dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes
On Fri, 27 Jan 2017 09:57:03 -0500 Aaron Conole wrote: > diff --git a/lib/librte_eal/common/include/rte_eal.h > b/lib/librte_eal/common/include/rte_eal.h > index 03fee50..46e427f 100644 > --- a/lib/librte_eal/common/include/rte_eal.h > +++ b/lib/librte_eal/common/include/rte_eal.h > @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void); > * function call and should not be further interpreted by the > * application. The EAL does not take any ownership of the memory used > * for either the argv array, or its members. > - * - On failure, a negative error value. > + * - On failure, -1 and rte_errno is set to a value indicating the cause > + * for failure. > + * > + * The error codes returned via rte_errno: > + * EACCES indicates a permissions issue. > + * > + * EAGAIN indicates either a bus or system resource was not available, > + *try again. > + * > + * EALREADY indicates that the rte_eal_init function has already been > + * called, and cannot be called again. > + * > + * EINVAL indicates invalid parameters were passed as argv/argc. > + * > + * EIO indicates failure to setup the logging handlers. This is usually > + * caused by an out-of-memory condition. > + * > + * ENODEV indicates memory setup issues. > + * > + * ENOTSUP indicates that the EAL cannot initialize on this system. > + * > + * EUNATCH indicates that the PCI bus is either not present, or is not > + * readable by the eal. > */ > int rte_eal_init(int argc, char **argv); Why use rte_errno? Most DPDK calls just return negative value on error which corresponds to error number. Are you trying to keep ABI compatibility? Doesn't make sense because before all these errors were panic's no working application is going to care.
Re: [dpdk-dev] [PATCH 15/25] eal: do not panic on alarm init
On Fri, Jan 27, 2017 at 08:31:55AM -0800, Stephen Hemminger wrote:
> On Fri, 27 Jan 2017 09:56:53 -0500
> Aaron Conole wrote:
>
> > + if (rte_eal_alarm_init() < 0) {
> > + RTE_LOG (ERR, EAL, "Cannot init interrupt-handling thread\n");
> > + /* rte_eal_alarm_init sets rte_errno on failure. */
> > + errno = rte_errno;
>
> Hmm. DPDK in general does not reset errno but instead uses error code
> directly on return (best) or in some cases rte_errno
I think we'll disagree on what way of returning error codes is best :-), but
yes, DPDK does not generally modify errno.
Re: [dpdk-dev] [PATCH] mk: fix build of assembly files for ARM64
2017-01-18 12:31, Zbigniew Bodek: > > On 17.01.2017 23:45, Thomas Monjalon wrote: > > 2017-01-17 15:35, zbigniew.bo...@caviumnetworks.com: > >> -# for now, we don't use as but nasm. > >> -# AS = $(CROSS)as > > > > It looks to be a very very old comment. > > > >> +ifeq ($(CONFIG_RTE_ARCH_X86),y) > >> AS= nasm > > > > There is no asm file in DPDK as far as I know. > > So why would we have a dependency on nasm for x86? > > Yes, there is no such file now. We were to add assembly code but > eventually we decided to put it in a separate library. Nevertheless this > fix should be harmless if there is no ASM file and will behave correctly > if someone will add ASM file in the future. Please remove the ifeq and keep only $(CROSS)as as below. > >> +else > >> +AS= $(CROSS)as > >> +endif > >
Re: [dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes
On Fri, Jan 27, 2017 at 08:33:46AM -0800, Stephen Hemminger wrote: > On Fri, 27 Jan 2017 09:57:03 -0500 > Aaron Conole wrote: > > > diff --git a/lib/librte_eal/common/include/rte_eal.h > > b/lib/librte_eal/common/include/rte_eal.h > > index 03fee50..46e427f 100644 > > --- a/lib/librte_eal/common/include/rte_eal.h > > +++ b/lib/librte_eal/common/include/rte_eal.h > > @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void); > > * function call and should not be further interpreted by the > > * application. The EAL does not take any ownership of the memory used > > * for either the argv array, or its members. > > - * - On failure, a negative error value. > > + * - On failure, -1 and rte_errno is set to a value indicating the cause > > + * for failure. > > + * > > + * The error codes returned via rte_errno: > > + * EACCES indicates a permissions issue. > > + * > > + * EAGAIN indicates either a bus or system resource was not available, > > + *try again. > > + * > > + * EALREADY indicates that the rte_eal_init function has already been > > + * called, and cannot be called again. > > + * > > + * EINVAL indicates invalid parameters were passed as argv/argc. > > + * > > + * EIO indicates failure to setup the logging handlers. This is > > usually > > + * caused by an out-of-memory condition. > > + * > > + * ENODEV indicates memory setup issues. > > + * > > + * ENOTSUP indicates that the EAL cannot initialize on this system. > > + * > > + * EUNATCH indicates that the PCI bus is either not present, or is not > > + * readable by the eal. > > */ > > int rte_eal_init(int argc, char **argv); > > Why use rte_errno? > Most DPDK calls just return negative value on error which corresponds to > error number. > Are you trying to keep ABI compatibility? Doesn't make sense because before > all these > errors were panic's no working application is going to care. Either will work, but I actually prefer this way. I view using rte_errno to be better as it can work in just about all cases, including with functions which return pointers. This allows you to have a standard method across all functions for returning error codes, and it only requires a single sentinal value to indicate error, rather than using a whole range of values. /Bruce
Re: [dpdk-dev] [PATCH] doc: update examples list for API
On 1/27/2017 3:56 PM, Thomas Monjalon wrote: > 2017-01-27 11:55, Ferruh Yigit: >> These files are linked to API documentation as usage samples, added >> missing examples files and sorted list alphabetically. >> >> Signed-off-by: Ferruh Yigit > > Why not replacing this list with a "find examples -type f" in > mk/rte.sdkdoc.mk? Yes it is good idea, I will try.
[dpdk-dev] [PATCH v2] doc: automate examples file list for API doc
These files are linked to API documentation as usage samples, list of files created automatically during doc creation. Remove manually updated old one. Signed-off-by: Ferruh Yigit --- doc/api/doxy-api.conf | 1 - doc/api/examples.dox | 115 -- mk/rte.sdkdoc.mk | 14 +- 3 files changed, 13 insertions(+), 117 deletions(-) delete mode 100644 doc/api/examples.dox diff --git a/doc/api/doxy-api.conf b/doc/api/doxy-api.conf index 6892315..a92dd3c 100644 --- a/doc/api/doxy-api.conf +++ b/doc/api/doxy-api.conf @@ -30,7 +30,6 @@ PROJECT_NAME= DPDK INPUT = doc/api/doxy-api-index.md \ - doc/api/examples.dox \ drivers/net/bonding \ lib/librte_eal/common/include \ lib/librte_eal/common/include/generic \ diff --git a/doc/api/examples.dox b/doc/api/examples.dox deleted file mode 100644 index c13e574..000 --- a/doc/api/examples.dox +++ /dev/null @@ -1,115 +0,0 @@ -/** -@page examples DPDK Example Programs - -@example bond/main.c -@example cmdline/commands.c -@example cmdline/main.c -@example cmdline/parse_obj_list.c -@example distributor/main.c -@example dpdk_qat/crypto.c -@example dpdk_qat/main.c -@example ethtool/ethtool-app/ethapp.c -@example ethtool/ethtool-app/main.c -@example ethtool/lib/rte_ethtool.c -@example exception_path/main.c -@example helloworld/main.c -@example ip_fragmentation/main.c -@example ip_pipeline/config_check.c -@example ip_pipeline/config_parse.c -@example ip_pipeline/config_parse_tm.c -@example ip_pipeline/cpu_core_map.c -@example ip_pipeline/init.c -@example ip_pipeline/main.c -@example ip_pipeline/pipeline/pipeline_common_be.c -@example ip_pipeline/pipeline/pipeline_common_fe.c -@example ip_pipeline/pipeline/pipeline_firewall_be.c -@example ip_pipeline/pipeline/pipeline_firewall.c -@example ip_pipeline/pipeline/pipeline_flow_actions_be.c -@example ip_pipeline/pipeline/pipeline_flow_actions.c -@example ip_pipeline/pipeline/pipeline_flow_classification_be.c -@example ip_pipeline/pipeline/pipeline_flow_classification.c -@example ip_pipeline/pipeline/pipeline_master_be.c -@example ip_pipeline/pipeline/pipeline_master.c -@example ip_pipeline/pipeline/pipeline_passthrough_be.c -@example ip_pipeline/pipeline/pipeline_passthrough.c -@example ip_pipeline/pipeline/pipeline_routing_be.c -@example ip_pipeline/pipeline/pipeline_routing.c -@example ip_pipeline/thread.c -@example ip_pipeline/thread_fe.c -@example ip_reassembly/main.c -@example ipv4_multicast/main.c -@example kni/main.c -@example l2fwd-crypto/main.c -@example l2fwd-jobstats/main.c -@example l2fwd-keepalive/main.c -@example l2fwd/main.c -@example l3fwd-acl/main.c -@example l3fwd/main.c -@example l3fwd-power/main.c -@example l3fwd-vf/main.c -@example link_status_interrupt/main.c -@example load_balancer/config.c -@example load_balancer/init.c -@example load_balancer/main.c -@example load_balancer/runtime.c -@example flow_distributor/distributor/args.c -@example flow_distributor/distributor/init.c -@example flow_distributor/distributor/main.c -@example flow_distributor/node/node.c -@example multi_process/client_server_mp/mp_client/client.c -@example multi_process/client_server_mp/mp_server/args.c -@example multi_process/client_server_mp/mp_server/init.c -@example multi_process/client_server_mp/mp_server/main.c -@example multi_process/l2fwd_fork/flib.c -@example multi_process/l2fwd_fork/main.c -@example multi_process/simple_mp/main.c -@example multi_process/simple_mp/mp_commands.c -@example multi_process/symmetric_mp/main.c -@example netmap_compat/bridge/bridge.c -@example netmap_compat/lib/compat_netmap.c -@example packet_ordering/main.c -@example performance-thread/common/arch/x86/ctx.c -@example performance-thread/common/lthread.c -@example performance-thread/common/lthread_cond.c -@example performance-thread/common/lthread_diag.c -@example performance-thread/common/lthread_mutex.c -@example performance-thread/common/lthread_sched.c -@example performance-thread/common/lthread_tls.c -@example performance-thread/l3fwd-thread/main.c -@example performance-thread/pthread_shim/main.c -@example performance-thread/pthread_shim/pthread_shim.c -@example ptpclient/ptpclient.c -@example qos_meter/main.c -@example qos_meter/rte_policer.c -@example qos_sched/app_thread.c -@example qos_sched/args.c -@example qos_sched/cfg_file.c -@example qos_sched/cmdline.c -@example qos_sched/init.c -@example qos_sched/main.c -@example qos_sched/stats.c -@example quota_watermark/qw/args.c -@example quota_watermark/qwctl/commands.c -@example quota_watermark/qwctl/qwctl.c -@example quota_watermark/qw/init.c -@example quota_watermark/qw/main.c -@example rxtx_callbacks/main.c -@example skeleton/basicfwd.c -@example tep_termination/main.c -@example tep_termination/vxlan.c -@example tep_termination/vxlan_setup.c -@example timer/main.c -@example vhost/main.c -@example vhost_
Re: [dpdk-dev] [PATCH 25/25] rte_eal_init: add info about rte_errno codes
On Fri, 27 Jan 2017 16:47:40 + Bruce Richardson wrote: > On Fri, Jan 27, 2017 at 08:33:46AM -0800, Stephen Hemminger wrote: > > On Fri, 27 Jan 2017 09:57:03 -0500 > > Aaron Conole wrote: > > > > > diff --git a/lib/librte_eal/common/include/rte_eal.h > > > b/lib/librte_eal/common/include/rte_eal.h > > > index 03fee50..46e427f 100644 > > > --- a/lib/librte_eal/common/include/rte_eal.h > > > +++ b/lib/librte_eal/common/include/rte_eal.h > > > @@ -159,7 +159,29 @@ int rte_eal_iopl_init(void); > > > * function call and should not be further interpreted by the > > > * application. The EAL does not take any ownership of the memory > > > used > > > * for either the argv array, or its members. > > > - * - On failure, a negative error value. > > > + * - On failure, -1 and rte_errno is set to a value indicating the > > > cause > > > + * for failure. > > > + * > > > + * The error codes returned via rte_errno: > > > + * EACCES indicates a permissions issue. > > > + * > > > + * EAGAIN indicates either a bus or system resource was not > > > available, > > > + *try again. > > > + * > > > + * EALREADY indicates that the rte_eal_init function has already been > > > + * called, and cannot be called again. > > > + * > > > + * EINVAL indicates invalid parameters were passed as argv/argc. > > > + * > > > + * EIO indicates failure to setup the logging handlers. This is > > > usually > > > + * caused by an out-of-memory condition. > > > + * > > > + * ENODEV indicates memory setup issues. > > > + * > > > + * ENOTSUP indicates that the EAL cannot initialize on this system. > > > + * > > > + * EUNATCH indicates that the PCI bus is either not present, or is > > > not > > > + * readable by the eal. > > > */ > > > int rte_eal_init(int argc, char **argv); > > > > Why use rte_errno? > > Most DPDK calls just return negative value on error which corresponds to > > error number. > > Are you trying to keep ABI compatibility? Doesn't make sense because before > > all these > > errors were panic's no working application is going to care. > > Either will work, but I actually prefer this way. I view using rte_errno > to be better as it can work in just about all cases, including with > functions which return pointers. This allows you to have a standard > method across all functions for returning error codes, and it only > requires a single sentinal value to indicate error, rather than using a > whole range of values. The problem is DPDK is getting more inconsistent on how this is done. As long as error returns are always same as kernel/glibc errno's it really doesn't matter much which way the value is returned from a technical point of view but the inconsistency is sure to be a usability problem and source of errors.
[dpdk-dev] [PATCH 4/9] net/bnx2x: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit --- drivers/net/bnx2x/bnx2x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/bnx2x/bnx2x.c b/drivers/net/bnx2x/bnx2x.c index 0d16a73..cc380bd 100644 --- a/drivers/net/bnx2x/bnx2x.c +++ b/drivers/net/bnx2x/bnx2x.c @@ -2220,7 +2220,7 @@ int bnx2x_tx_encap(struct bnx2x_tx_queue *txq, struct rte_mbuf *m0) } PMD_TX_LOG(DEBUG, - "start bd: nbytes %d flags %x vlan %x\n", + "start bd: nbytes %d flags %x vlan %x", tx_start_bd->nbytes, tx_start_bd->bd_flags.as_bitfield, tx_start_bd->vlan_or_ethertype); -- 2.9.3
[dpdk-dev] [PATCH 3/9] net/e1000: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/e1000/em_ethdev.c | 4 ++--
drivers/net/e1000/igb_ethdev.c | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index d67fdef..d778785 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -639,7 +639,7 @@ eth_em_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int),
0);
if (intr_handle->intr_vec == NULL) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
- " intr_vec\n",
dev->data->nb_rx_queues);
+ " intr_vec",
dev->data->nb_rx_queues);
return -ENOMEM;
}
@@ -736,7 +736,7 @@ eth_em_start(struct rte_eth_dev *dev)
(void *)dev);
if (dev->data->dev_conf.intr_conf.lsc != 0)
PMD_INIT_LOG(INFO, "lsc won't enable because of"
-" no intr multiplex\n");
+" no intr multiplexn");
}
/* check if rxq interrupt is enabled */
if (dev->data->dev_conf.intr_conf.rxq != 0)
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 8843dd1..d939774 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -1292,7 +1292,7 @@ eth_igb_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int), 0);
if (intr_handle->intr_vec == NULL) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
+" intr_vec", dev->data->nb_rx_queues);
return -ENOMEM;
}
}
@@ -1399,7 +1399,7 @@ eth_igb_start(struct rte_eth_dev *dev)
(void *)dev);
if (dev->data->dev_conf.intr_conf.lsc != 0)
PMD_INIT_LOG(INFO, "lsc won't enable because of"
-" no intr multiplex\n");
+" no intr multiplex");
}
/* check if rxq interrupt is enabled */
@@ -3159,7 +3159,7 @@ igbvf_dev_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int), 0);
if (!intr_handle->intr_vec) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
+" intr_vec", dev->data->nb_rx_queues);
return -ENOMEM;
}
}
@@ -3378,7 +3378,7 @@ eth_igb_rss_reta_update(struct rte_eth_dev *dev,
if (reta_size != ETH_RSS_RETA_SIZE_128) {
PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
"(%d) doesn't match the number hardware can supported "
- "(%d)\n", reta_size, ETH_RSS_RETA_SIZE_128);
+ "(%d)", reta_size, ETH_RSS_RETA_SIZE_128);
return -EINVAL;
}
@@ -3419,7 +3419,7 @@ eth_igb_rss_reta_query(struct rte_eth_dev *dev,
if (reta_size != ETH_RSS_RETA_SIZE_128) {
PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
"(%d) doesn't match the number hardware can supported "
- "(%d)\n", reta_size, ETH_RSS_RETA_SIZE_128);
+ "(%d)", reta_size, ETH_RSS_RETA_SIZE_128);
return -EINVAL;
}
@@ -3540,7 +3540,7 @@ eth_igb_syn_filter_handle(struct rte_eth_dev *dev,
(struct rte_eth_syn_filter *)arg);
break;
default:
- PMD_DRV_LOG(ERR, "unsupported operation %u\n", filter_op);
+ PMD_DRV_LOG(ERR, "unsupported operation %u", filter_op);
ret = -EINVAL;
break;
}
--
2.9.3
[dpdk-dev] [PATCH 1/9] net/ixgbe: remove redundant EOL character from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/ixgbe/ixgbe_ethdev.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c b/drivers/net/ixgbe/ixgbe_ethdev.c
index edbf75b..5b625a3 100644
--- a/drivers/net/ixgbe/ixgbe_ethdev.c
+++ b/drivers/net/ixgbe/ixgbe_ethdev.c
@@ -2459,7 +2459,7 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int), 0);
if (intr_handle->intr_vec == NULL) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
+" intr_vec", dev->data->nb_rx_queues);
return -ENOMEM;
}
}
@@ -2579,7 +2579,7 @@ ixgbe_dev_start(struct rte_eth_dev *dev)
ixgbe_dev_interrupt_handler, dev);
if (dev->data->dev_conf.intr_conf.lsc != 0)
PMD_INIT_LOG(INFO, "lsc won't enable because of"
-" no intr multiplex\n");
+" no intr multiplex");
}
/* check if rxq interrupt is enabled */
@@ -4282,7 +4282,7 @@ ixgbe_dev_rss_reta_update(struct rte_eth_dev *dev,
if (reta_size != sp_reta_size) {
PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
"(%d) doesn't match the number hardware can supported "
- "(%d)\n", reta_size, sp_reta_size);
+ "(%d)", reta_size, sp_reta_size);
return -EINVAL;
}
@@ -4329,7 +4329,7 @@ ixgbe_dev_rss_reta_query(struct rte_eth_dev *dev,
if (reta_size != sp_reta_size) {
PMD_DRV_LOG(ERR, "The size of hash lookup table configured "
"(%d) doesn't match the number hardware can supported "
- "(%d)\n", reta_size, sp_reta_size);
+ "(%d)", reta_size, sp_reta_size);
return -EINVAL;
}
@@ -4589,7 +4589,7 @@ ixgbevf_dev_start(struct rte_eth_dev *dev)
dev->data->nb_rx_queues * sizeof(int), 0);
if (intr_handle->intr_vec == NULL) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
+" intr_vec", dev->data->nb_rx_queues);
return -ENOMEM;
}
}
@@ -6056,7 +6056,7 @@ ixgbe_syn_filter_handle(struct rte_eth_dev *dev,
(struct rte_eth_syn_filter *)arg);
break;
default:
- PMD_DRV_LOG(ERR, "unsupported operation %u\n", filter_op);
+ PMD_DRV_LOG(ERR, "unsupported operation %u", filter_op);
ret = -EINVAL;
break;
}
@@ -8199,7 +8199,7 @@ int ixgbe_disable_sec_tx_path_generic(struct ixgbe_hw *hw)
/* For informational purposes only */
if (i >= IXGBE_MAX_SECTX_POLL)
PMD_DRV_LOG(DEBUG, "Tx unit being enabled before security "
-"path fully disabled. Continuing with init.\n");
+"path fully disabled. Continuing with init.");
return IXGBE_SUCCESS;
}
--
2.9.3
[dpdk-dev] [PATCH 2/9] net/i40e: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/i40e/i40e_ethdev.c| 51 ++-
drivers/net/i40e/i40e_ethdev_vf.c | 31
drivers/net/i40e/i40e_fdir.c | 2 +-
drivers/net/i40e/i40e_pf.c| 4 +--
drivers/net/i40e/i40e_rxtx.c | 2 +-
5 files changed, 43 insertions(+), 47 deletions(-)
diff --git a/drivers/net/i40e/i40e_ethdev.c b/drivers/net/i40e/i40e_ethdev.c
index 0937dc4..4492bcc 100644
--- a/drivers/net/i40e/i40e_ethdev.c
+++ b/drivers/net/i40e/i40e_ethdev.c
@@ -1894,7 +1894,7 @@ i40e_dev_start(struct rte_eth_dev *dev)
0);
if (!intr_handle->intr_vec) {
PMD_INIT_LOG(ERR,
- "Failed to allocate %d rx_queues intr_vec\n",
+ "Failed to allocate %d rx_queues intr_vec",
dev->data->nb_rx_queues);
return -ENOMEM;
}
@@ -1969,7 +1969,7 @@ i40e_dev_start(struct rte_eth_dev *dev)
if (dev->data->dev_conf.intr_conf.lsc != 0)
PMD_INIT_LOG(INFO,
- "lsc won't enable because of no intr
multiplex\n");
+ "lsc won't enable because of no intr
multiplex");
} else if (dev->data->dev_conf.intr_conf.lsc != 0) {
ret = i40e_aq_set_phy_int_mask(hw,
~(I40E_AQ_EVENT_LINK_UPDOWN |
@@ -2936,7 +2936,7 @@ i40e_vlan_tpid_set(struct rte_eth_dev *dev,
else {
ret = -EINVAL;
PMD_DRV_LOG(ERR,
- "Unsupported vlan type in single vlan.\n");
+ "Unsupported vlan type in single vlan.");
return ret;
}
break;
@@ -3498,7 +3498,7 @@ i40e_dev_rss_reta_update(struct rte_eth_dev *dev,
if (reta_size != lut_size ||
reta_size > ETH_RSS_RETA_SIZE_512) {
PMD_DRV_LOG(ERR,
- "The size of hash lookup table configured (%d) doesn't
match the number hardware can supported (%d)\n",
+ "The size of hash lookup table configured (%d) doesn't
match the number hardware can supported (%d)",
reta_size, lut_size);
return -EINVAL;
}
@@ -3539,7 +3539,7 @@ i40e_dev_rss_reta_query(struct rte_eth_dev *dev,
if (reta_size != lut_size ||
reta_size > ETH_RSS_RETA_SIZE_512) {
PMD_DRV_LOG(ERR,
- "The size of hash lookup table configured (%d) doesn't
match the number hardware can supported (%d)\n",
+ "The size of hash lookup table configured (%d) doesn't
match the number hardware can supported (%d)",
reta_size, lut_size);
return -EINVAL;
}
@@ -4586,7 +4586,7 @@ i40e_enable_pf_lb(struct i40e_pf *pf)
ret = i40e_aq_update_vsi_params(hw, &ctxt, NULL);
if (ret)
- PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d\n",
+ PMD_DRV_LOG(ERR, "update vsi switch failed, aq_err=%d",
hw->aq.asq_last_status);
}
@@ -5183,11 +5183,11 @@ i40e_pf_setup(struct i40e_pf *pf)
else if (hw->func_caps.rss_table_size == ETH_RSS_RETA_SIZE_512)
settings.hash_lut_size = I40E_HASH_LUT_SIZE_512;
else {
- PMD_DRV_LOG(ERR, "Hash lookup table size (%u) not supported\n",
- hw->func_caps.rss_table_size);
+ PMD_DRV_LOG(ERR, "Hash lookup table size (%u) not supported",
+ hw->func_caps.rss_table_size);
return I40E_ERR_PARAM;
}
- PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table size: %u\n",
+ PMD_DRV_LOG(INFO, "Hardware capability of hash lookup table size: %u",
hw->func_caps.rss_table_size);
pf->hash_lut_size = hw->func_caps.rss_table_size;
@@ -5870,7 +5870,7 @@ i40e_add_macvlan_filters(struct i40e_vsi *vsi,
flags = I40E_AQC_MACVLAN_ADD_HASH_MATCH;
break;
default:
- PMD_DRV_LOG(ERR, "Invalid MAC match type\n");
+ PMD_DRV_LOG(ERR, "Invalid MAC match type");
ret = I40E_ERR_PARAM;
goto DONE;
}
@@ -5945,7 +5945,7 @@ i40e_remove_macvlan_filters(struct i40e_vsi *vsi,
flags = I40E_AQC_MACVLAN_DEL_HASH_MATCH;
break;
default:
- PMD_DRV_LOG(ERR, "Invalid MAC filter type\n");
+ PMD_DRV_LOG(ERR, "Inva
[dpdk-dev] [PATCH 5/9] net/ena: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/ena/ena_ethdev.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ena/ena_ethdev.c b/drivers/net/ena/ena_ethdev.c
index a580345..ff36c64 100644
--- a/drivers/net/ena/ena_ethdev.c
+++ b/drivers/net/ena/ena_ethdev.c
@@ -746,7 +746,7 @@ static int ena_queue_restart_all(struct rte_eth_dev *dev,
if (rc) {
PMD_INIT_LOG(ERR,
-"failed to restart queue %d
type(%d)\n",
+"failed to restart queue %d
type(%d)",
i, ring_type);
return -1;
}
@@ -772,7 +772,7 @@ static int ena_check_valid_conf(struct ena_adapter *adapter)
uint32_t max_frame_len = ena_get_mtu_conf(adapter);
if (max_frame_len > adapter->max_mtu) {
- PMD_INIT_LOG(ERR, "Unsupported MTU of %d\n", max_frame_len);
+ PMD_INIT_LOG(ERR, "Unsupported MTU of %d", max_frame_len);
return -1;
}
@@ -799,7 +799,7 @@ ena_calc_queue_size(struct ena_com_dev *ena_dev,
queue_size = rte_align32pow2(queue_size >> 1);
if (queue_size == 0) {
- PMD_INIT_LOG(ERR, "Invalid queue size\n");
+ PMD_INIT_LOG(ERR, "Invalid queue size");
return -EFAULT;
}
@@ -937,7 +937,7 @@ static int ena_queue_restart(struct ena_ring *ring)
rc = ena_populate_rx_queue(ring, ring->ring_size);
if ((unsigned int)rc != ring->ring_size) {
- PMD_INIT_LOG(ERR, "Failed to populate rx ring !\n");
+ PMD_INIT_LOG(ERR, "Failed to populate rx ring !");
return (-1);
}
@@ -1293,7 +1293,7 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
pci_dev = RTE_DEV_TO_PCI(eth_dev->device);
adapter->pdev = pci_dev;
- PMD_INIT_LOG(INFO, "Initializing %x:%x:%x.%d\n",
+ PMD_INIT_LOG(INFO, "Initializing %x:%x:%x.%d",
pci_dev->addr.domain,
pci_dev->addr.bus,
pci_dev->addr.devid,
@@ -1310,7 +1310,7 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
else if (adapter->regs)
ena_dev->tx_mem_queue_type = ENA_ADMIN_PLACEMENT_POLICY_HOST;
else
- PMD_INIT_LOG(CRIT, "Failed to access registers BAR(%d)\n",
+ PMD_INIT_LOG(CRIT, "Failed to access registers BAR(%d)",
ENA_REGS_BAR);
ena_dev->reg_bar = adapter->regs;
@@ -1324,7 +1324,7 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
/* device specific initialization routine */
rc = ena_device_init(ena_dev, &get_feat_ctx);
if (rc) {
- PMD_INIT_LOG(CRIT, "Failed to init ENA device\n");
+ PMD_INIT_LOG(CRIT, "Failed to init ENA device");
return -1;
}
@@ -1332,7 +1332,7 @@ static int eth_ena_dev_init(struct rte_eth_dev *eth_dev)
if (get_feat_ctx.max_queues.max_llq_num == 0) {
PMD_INIT_LOG(ERR,
"Trying to use LLQ but llq_num is 0.\n"
-"Fall back into regular queues.\n");
+"Fall back into regular queues.");
ena_dev->tx_mem_queue_type =
ENA_ADMIN_PLACEMENT_POLICY_HOST;
adapter->num_queues =
@@ -1390,7 +1390,7 @@ static int ena_dev_configure(struct rte_eth_dev *dev)
if (!(adapter->state == ENA_ADAPTER_STATE_INIT ||
adapter->state == ENA_ADAPTER_STATE_STOPPED)) {
- PMD_INIT_LOG(ERR, "Illegal adapter state: %d\n",
+ PMD_INIT_LOG(ERR, "Illegal adapter state: %d",
adapter->state);
return -1;
}
--
2.9.3
[dpdk-dev] [PATCH 6/9] net/nfp: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/nfp/nfp_net.c | 58 +++
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/net/nfp/nfp_net.c b/drivers/net/nfp/nfp_net.c
index 1020d9e..173bebf 100644
--- a/drivers/net/nfp/nfp_net.c
+++ b/drivers/net/nfp/nfp_net.c
@@ -374,12 +374,12 @@ __nfp_net_reconfig(struct nfp_net_hw *hw, uint32_t update)
if (new == 0)
break;
if (new & NFP_NET_CFG_UPDATE_ERR) {
- PMD_INIT_LOG(ERR, "Reconfig error: 0x%08x\n", new);
+ PMD_INIT_LOG(ERR, "Reconfig error: 0x%08x", new);
return -1;
}
if (cnt >= NFP_NET_POLL_TIMEOUT) {
PMD_INIT_LOG(ERR, "Reconfig timeout for 0x%08x after"
- " %dms\n", update, cnt);
+ " %dms", update, cnt);
rte_panic("Exiting\n");
}
nanosleep(&wait, 0); /* waiting for a 1ms */
@@ -423,7 +423,7 @@ nfp_net_reconfig(struct nfp_net_hw *hw, uint32_t ctrl,
uint32_t update)
* Reconfig errors imply situations where they can be handled.
* Otherwise, rte_panic is called inside __nfp_net_reconfig
*/
- PMD_INIT_LOG(ERR, "Error nfp_net reconfig for ctrl: %x update: %x\n",
+ PMD_INIT_LOG(ERR, "Error nfp_net reconfig for ctrl: %x update: %x",
ctrl, update);
return -EIO;
}
@@ -453,7 +453,7 @@ nfp_net_configure(struct rte_eth_dev *dev)
* called after that internal process
*/
- PMD_INIT_LOG(DEBUG, "Configure\n");
+ PMD_INIT_LOG(DEBUG, "Configure");
dev_conf = &dev->data->dev_conf;
rxmode = &dev_conf->rxmode;
@@ -461,7 +461,7 @@ nfp_net_configure(struct rte_eth_dev *dev)
/* Checking TX mode */
if (txmode->mq_mode) {
- PMD_INIT_LOG(INFO, "TX mq_mode DCB and VMDq not supported\n");
+ PMD_INIT_LOG(INFO, "TX mq_mode DCB and VMDq not supported");
return -EINVAL;
}
@@ -471,13 +471,13 @@ nfp_net_configure(struct rte_eth_dev *dev)
update = NFP_NET_CFG_UPDATE_RSS;
new_ctrl = NFP_NET_CFG_CTRL_RSS;
} else {
- PMD_INIT_LOG(INFO, "RSS not supported\n");
+ PMD_INIT_LOG(INFO, "RSS not supported");
return -EINVAL;
}
}
if (rxmode->split_hdr_size) {
- PMD_INIT_LOG(INFO, "rxmode does not support split header\n");
+ PMD_INIT_LOG(INFO, "rxmode does not support split header");
return -EINVAL;
}
@@ -485,13 +485,13 @@ nfp_net_configure(struct rte_eth_dev *dev)
if (hw->cap & NFP_NET_CFG_CTRL_RXCSUM) {
new_ctrl |= NFP_NET_CFG_CTRL_RXCSUM;
} else {
- PMD_INIT_LOG(INFO, "RXCSUM not supported\n");
+ PMD_INIT_LOG(INFO, "RXCSUM not supported");
return -EINVAL;
}
}
if (rxmode->hw_vlan_filter) {
- PMD_INIT_LOG(INFO, "VLAN filter not supported\n");
+ PMD_INIT_LOG(INFO, "VLAN filter not supported");
return -EINVAL;
}
@@ -499,13 +499,13 @@ nfp_net_configure(struct rte_eth_dev *dev)
if (hw->cap & NFP_NET_CFG_CTRL_RXVLAN) {
new_ctrl |= NFP_NET_CFG_CTRL_RXVLAN;
} else {
- PMD_INIT_LOG(INFO, "hw vlan strip not supported\n");
+ PMD_INIT_LOG(INFO, "hw vlan strip not supported");
return -EINVAL;
}
}
if (rxmode->hw_vlan_extend) {
- PMD_INIT_LOG(INFO, "VLAN extended not supported\n");
+ PMD_INIT_LOG(INFO, "VLAN extended not supported");
return -EINVAL;
}
@@ -517,12 +517,12 @@ nfp_net_configure(struct rte_eth_dev *dev)
/* this is handled in rte_eth_dev_configure */
if (rxmode->hw_strip_crc) {
- PMD_INIT_LOG(INFO, "strip CRC not supported\n");
+ PMD_INIT_LOG(INFO, "strip CRC not supported");
return -EINVAL;
}
if (rxmode->enable_scatter) {
- PMD_INIT_LOG(INFO, "Scatter not supported\n");
+ PMD_INIT_LOG(INFO, "Scatter not supported");
return -EINVAL;
}
@@ -638,7 +638,7 @@ nfp_configure_rx_interrupt(struct rte_eth_dev *dev,
dev->data->nb_rx_queues * sizeof(int), 0);
if (!intr_handle->intr_vec) {
PMD_INIT_LOG(ERR, "Failed to allocate %d rx_queues"
-" intr_vec\n", dev->data->nb_rx_queues);
[dpdk-dev] [PATCH 7/9] net/qede: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/qede/qede_rxtx.c | 68 ++--
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/net/qede/qede_rxtx.c b/drivers/net/qede/qede_rxtx.c
index 821ffbc..01ea9b4 100644
--- a/drivers/net/qede/qede_rxtx.c
+++ b/drivers/net/qede/qede_rxtx.c
@@ -69,7 +69,7 @@ static void qede_tx_queue_release_mbufs(struct qede_tx_queue
*txq)
{
unsigned int i;
- PMD_TX_LOG(DEBUG, txq, "releasing %u mbufs\n", txq->nb_tx_desc);
+ PMD_TX_LOG(DEBUG, txq, "releasing %u mbufs", txq->nb_tx_desc);
if (txq->sw_tx_ring) {
for (i = 0; i < txq->nb_tx_desc; i++) {
@@ -506,7 +506,7 @@ qede_update_rx_prod(struct qede_dev *edev, struct
qede_rx_queue *rxq)
*/
rte_wmb();
- PMD_RX_LOG(DEBUG, rxq, "bd_prod %u cqe_prod %u\n", bd_prod, cqe_prod);
+ PMD_RX_LOG(DEBUG, rxq, "bd_prod %u cqe_prod %u", bd_prod, cqe_prod);
}
static int qede_start_queues(struct rte_eth_dev *eth_dev, bool clear_stats)
@@ -827,7 +827,7 @@ qede_process_sg_pkts(void *p_rxq, struct rte_mbuf *rx_mb,
pkt_len;
if (unlikely(!cur_size)) {
PMD_RX_LOG(ERR, rxq, "Length is 0 while %u BDs"
- " left for mapping jumbo\n", num_segs);
+ " left for mapping jumbo", num_segs);
qede_recycle_rx_bd_ring(rxq, qdev, num_segs);
return -EINVAL;
}
@@ -885,7 +885,7 @@ qede_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
cqe_type = cqe->fast_path_regular.type;
if (unlikely(cqe_type == ETH_RX_CQE_TYPE_SLOW_PATH)) {
- PMD_RX_LOG(DEBUG, rxq, "Got a slowath CQE\n");
+ PMD_RX_LOG(DEBUG, rxq, "Got a slowath CQE");
qdev->ops->eth_cqe_completion(edev, fp->id,
(struct eth_slow_path_rx_cqe *)cqe);
@@ -907,7 +907,7 @@ qede_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
PMD_RX_LOG(DEBUG, rxq,
"CQE type = 0x%x, flags = 0x%x, vlan = 0x%x"
- " len = %u, parsing_flags = %d\n",
+ " len = %u, parsing_flags = %d",
cqe_type, fp_cqe->bitfields,
rte_le_to_cpu_16(fp_cqe->vlan_tag),
len, rte_le_to_cpu_16(fp_cqe->pars_flags.flags));
@@ -919,10 +919,10 @@ qede_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
rx_mb->ol_flags = 0;
if (qede_tunn_exist(parse_flag)) {
- PMD_RX_LOG(DEBUG, rxq, "Rx tunneled packet\n");
+ PMD_RX_LOG(DEBUG, rxq, "Rx tunneled packet");
if (unlikely(qede_check_tunn_csum_l4(parse_flag))) {
PMD_RX_LOG(ERR, rxq,
- "L4 csum failed, flags = 0x%x\n",
+ "L4 csum failed, flags = 0x%x",
parse_flag);
rxq->rx_hw_errors++;
rx_mb->ol_flags |= PKT_RX_L4_CKSUM_BAD;
@@ -934,17 +934,17 @@ qede_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
tunn_parse_flag);
}
} else {
- PMD_RX_LOG(DEBUG, rxq, "Rx non-tunneled packet\n");
+ PMD_RX_LOG(DEBUG, rxq, "Rx non-tunneled packet");
if (unlikely(qede_check_notunn_csum_l4(parse_flag))) {
PMD_RX_LOG(ERR, rxq,
- "L4 csum failed, flags = 0x%x\n",
+ "L4 csum failed, flags = 0x%x",
parse_flag);
rxq->rx_hw_errors++;
rx_mb->ol_flags |= PKT_RX_L4_CKSUM_BAD;
} else if (unlikely(qede_check_notunn_csum_l3(rx_mb,
parse_flag))) {
PMD_RX_LOG(ERR, rxq,
- "IP csum failed, flags = 0x%x\n",
+ "IP csum failed, flags = 0x%x",
parse_flag);
rxq->rx_hw_errors++;
rx_mb->ol_flags |= PKT_RX_IP_CKSUM_BAD;
@@ -954,12 +954,12 @@ qede_recv_pkts(void *p_rxq, struct rte_mbuf **rx_pkts,
uint16_t nb_pkts)
}
}
- PMD_RX_LOG(INFO, rxq, "packet_type 0x%x\n", rx_mb->packet_typ
[dpdk-dev] [PATCH 8/9] net/sfc: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit --- drivers/net/sfc/sfc_ev.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/sfc/sfc_ev.c b/drivers/net/sfc/sfc_ev.c index fe6de6f..f717faa 100644 --- a/drivers/net/sfc/sfc_ev.c +++ b/drivers/net/sfc/sfc_ev.c @@ -104,7 +104,7 @@ sfc_ev_rx(void *arg, __rte_unused uint32_t label, uint32_t id, evq->exception = B_TRUE; sfc_err(evq->sa, "EVQ %u RxQ %u invalid RX abort " - "(id=%#x size=%u flags=%#x); needs restart\n", + "(id=%#x size=%u flags=%#x); needs restart", evq->evq_index, sfc_rxq_sw_index(rxq), id, size, flags); goto done; @@ -119,7 +119,7 @@ sfc_ev_rx(void *arg, __rte_unused uint32_t label, uint32_t id, sfc_err(evq->sa, "EVQ %u RxQ %u completion out of order " - "(id=%#x delta=%u flags=%#x); needs restart\n", + "(id=%#x delta=%u flags=%#x); needs restart", evq->evq_index, sfc_rxq_sw_index(rxq), id, delta, flags); -- 2.9.3
[dpdk-dev] [PATCH 9/9] net/virtio: remove redundant EOL char from logs
Signed-off-by: Ferruh Yigit
---
drivers/net/virtio/virtio_ethdev.c | 14 +++---
drivers/net/virtio/virtio_rxtx.c | 2 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 4 ++--
drivers/net/virtio/virtio_user_ethdev.c | 8
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/virtio/virtio_ethdev.c
b/drivers/net/virtio/virtio_ethdev.c
index 1d51942..5e4cf3e 100644
--- a/drivers/net/virtio/virtio_ethdev.c
+++ b/drivers/net/virtio/virtio_ethdev.c
@@ -630,7 +630,7 @@ virtio_dev_promiscuous_enable(struct rte_eth_dev *dev)
int ret;
if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_RX)) {
- PMD_INIT_LOG(INFO, "host does not support rx control\n");
+ PMD_INIT_LOG(INFO, "host does not support rx control");
return;
}
@@ -653,7 +653,7 @@ virtio_dev_promiscuous_disable(struct rte_eth_dev *dev)
int ret;
if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_RX)) {
- PMD_INIT_LOG(INFO, "host does not support rx control\n");
+ PMD_INIT_LOG(INFO, "host does not support rx control");
return;
}
@@ -676,7 +676,7 @@ virtio_dev_allmulticast_enable(struct rte_eth_dev *dev)
int ret;
if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_RX)) {
- PMD_INIT_LOG(INFO, "host does not support rx control\n");
+ PMD_INIT_LOG(INFO, "host does not support rx control");
return;
}
@@ -699,7 +699,7 @@ virtio_dev_allmulticast_disable(struct rte_eth_dev *dev)
int ret;
if (!vtpci_with_feature(hw, VIRTIO_NET_F_CTRL_RX)) {
- PMD_INIT_LOG(INFO, "host does not support rx control\n");
+ PMD_INIT_LOG(INFO, "host does not support rx control");
return;
}
@@ -723,7 +723,7 @@ virtio_mtu_set(struct rte_eth_dev *dev, uint16_t mtu)
uint32_t frame_size = mtu + ether_hdr_len;
if (mtu < ETHER_MIN_MTU || frame_size > VIRTIO_MAX_RX_PKTLEN) {
- PMD_INIT_LOG(ERR, "MTU should be between %d and %d\n",
+ PMD_INIT_LOG(ERR, "MTU should be between %d and %d",
ETHER_MIN_MTU, VIRTIO_MAX_RX_PKTLEN - ether_hdr_len);
return -EINVAL;
}
@@ -1233,7 +1233,7 @@ virtio_queues_bind_intr(struct rte_eth_dev *dev)
uint32_t i;
struct virtio_hw *hw = dev->data->dev_private;
- PMD_INIT_LOG(INFO, "queue/interrupt binding\n");
+ PMD_INIT_LOG(INFO, "queue/interrupt binding");
for (i = 0; i < dev->data->nb_rx_queues; ++i) {
dev->intr_handle->intr_vec[i] = i + 1;
if (VTPCI_OPS(hw)->set_queue_irq(hw, hw->vqs[i * 2], i + 1) ==
@@ -1252,7 +1252,7 @@ virtio_queues_unbind_intr(struct rte_eth_dev *dev)
uint32_t i;
struct virtio_hw *hw = dev->data->dev_private;
- PMD_INIT_LOG(INFO, "queue/interrupt unbinding\n");
+ PMD_INIT_LOG(INFO, "queue/interrupt unbinding");
for (i = 0; i < dev->data->nb_rx_queues; ++i)
VTPCI_OPS(hw)->set_queue_irq(hw,
hw->vqs[i * VTNET_CQ],
diff --git a/drivers/net/virtio/virtio_rxtx.c b/drivers/net/virtio/virtio_rxtx.c
index b29565e..68d7d91 100644
--- a/drivers/net/virtio/virtio_rxtx.c
+++ b/drivers/net/virtio/virtio_rxtx.c
@@ -133,7 +133,7 @@ virtqueue_dequeue_burst_rx(struct virtqueue *vq, struct
rte_mbuf **rx_pkts,
cookie = (struct rte_mbuf *)vq->vq_descx[desc_idx].cookie;
if (unlikely(cookie == NULL)) {
- PMD_DRV_LOG(ERR, "vring descriptor with no mbuf cookie
at %u\n",
+ PMD_DRV_LOG(ERR, "vring descriptor with no mbuf cookie
at %u",
vq->vq_used_cons_idx);
break;
}
diff --git a/drivers/net/virtio/virtio_user/virtio_user_dev.c
b/drivers/net/virtio/virtio_user/virtio_user_dev.c
index 6617bc8..21ed00d 100644
--- a/drivers/net/virtio/virtio_user/virtio_user_dev.c
+++ b/drivers/net/virtio/virtio_user/virtio_user_dev.c
@@ -62,7 +62,7 @@ virtio_user_create_queue(struct virtio_user_dev *dev,
uint32_t queue_sel)
*/
callfd = eventfd(0, EFD_CLOEXEC | EFD_NONBLOCK);
if (callfd < 0) {
- PMD_DRV_LOG(ERR, "callfd error, %s\n", strerror(errno));
+ PMD_DRV_LOG(ERR, "callfd error, %s", strerror(errno));
return -1;
}
file.index = queue_sel;
@@ -105,7 +105,7 @@ virtio_user_kick_queue(struct virtio_user_dev *dev,
uint32_t queue_sel)
*/
kickfd = eventfd(0, EFD_CLOEXEC | EFD_NONBLOCK);
if (kickfd < 0) {
- PMD_DRV_LOG(ERR, "kickfd error, %s\n", strerror(errno));
+ PMD_DRV_LOG(ERR, "kickfd error, %s", strerror(errno));
return -1;
}
file.index = queue_sel;
diff --git a/dri
Re: [dpdk-dev] [PATCH 1/9] net/ixgbe: remove redundant EOL character from logs
On Fri, 27 Jan 2017 17:46:11 + Ferruh Yigit wrote: > Signed-off-by: Ferruh Yigit Thanks for fixing this. Acked-by: Stephen Hemminger
[dpdk-dev] [PATCH v5] ethdev: fix MAC address replay
This patch fixes a bug in replaying MAC address to the hardware
in rte_eth_dev_config_restore() routine. Added default MAC replay as well.
Fixes: 4bdefaade6d1 ("ethdev: VMDQ enhancements")
---
v2: Added default MAC replay & Code optimization.
v3: Covered a case (ex, SR-IOV) where multiple pools
exist in the mac_pool_sel array.
v4: removed a coding style warning.
v5: Added default MAC replay with dev_ops->mac_addr_add.
Signed-off-by: Steve Shin
---
lib/librte_ether/rte_ethdev.c | 48 ---
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 4790faf..15746a7 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -931,34 +931,40 @@ rte_eth_dev_config_restore(uint8_t port_id)
{
struct rte_eth_dev *dev;
struct rte_eth_dev_info dev_info;
- struct ether_addr addr;
+ struct ether_addr *addr;
uint16_t i;
uint32_t pool = 0;
+ uint64_t pool_mask;
dev = &rte_eth_devices[port_id];
rte_eth_dev_info_get(port_id, &dev_info);
- if (RTE_ETH_DEV_SRIOV(dev).active)
- pool = RTE_ETH_DEV_SRIOV(dev).def_vmdq_idx;
-
- /* replay MAC address configuration */
- for (i = 0; i < dev_info.max_mac_addrs; i++) {
- addr = dev->data->mac_addrs[i];
-
- /* skip zero address */
- if (is_zero_ether_addr(&addr))
- continue;
-
- /* add address to the hardware */
- if (*dev->dev_ops->mac_addr_add &&
- (dev->data->mac_pool_sel[i] & (1ULL << pool)))
- (*dev->dev_ops->mac_addr_add)(dev, &addr, i, pool);
- else {
- RTE_PMD_DEBUG_TRACE("port %d: MAC address array not
supported\n",
- port_id);
- /* exit the loop but not return an error */
- break;
+ /* replay MAC address configuration including default MAC */
+ addr = &dev->data->mac_addrs[0];
+ if (*dev->dev_ops->mac_addr_set != NULL)
+ (*dev->dev_ops->mac_addr_set)(dev, addr);
+ else if (*dev->dev_ops->mac_addr_add != NULL)
+ (*dev->dev_ops->mac_addr_add)(dev, addr, 0, pool);
+
+ if (*dev->dev_ops->mac_addr_add != NULL) {
+ for (i = 1; i < dev_info.max_mac_addrs; i++) {
+ addr = &dev->data->mac_addrs[i];
+
+ /* skip zero address */
+ if (is_zero_ether_addr(addr))
+ continue;
+
+ pool = 0;
+ pool_mask = dev->data->mac_pool_sel[i];
+
+ do {
+ if (pool_mask & 1ULL)
+ (*dev->dev_ops->mac_addr_add)(dev,
+ addr, i, pool);
+ pool_mask >>= 1;
+ pool++;
+ } while (pool_mask);
}
}
--
2.9.3
Re: [dpdk-dev] [PATCH 1/2] net/mlx5: fix VLAN validation
On 1/27/2017 3:35 PM, Nelio Laranjeiro wrote:
> TCI field is read from the wrong place due to an invalid cast. Moreover
> there is no need to limit matching to VID since PCP and DEI bits can be
> matched as well.
>
> Fixes: 12475fb203ad ("net/mlx5: support VLAN flow item")
>
> Signed-off-by: Nelio Laranjeiro
Series applied to dpdk-next-net/master, thanks.
("flow patter" added into both patch subject to limit the scope:
net/mlx5: fix flow pattern validation
net/mlx5: fix flow pattern VLAN validation
)
[dpdk-dev] [PATCH v5 0/3] new API to free consumed buffers in Tx ring
See request from 11/21/2016: http://dpdk.org/ml/archives/dev/2016-November/050585.html Add a new API to free consumed buffers on TX ring. This addresses two scenarios: 1) Flooding a packet and want to reuse existing mbuf to avoid a packet copy. Increment the reference count of the packet and poll new API until reference count is decremented. 2) Application runs out of mbufs, or resets and is preparing for additional run, call API to free consumed packets so processing can continue. API will return the number of packets freed (0-n) or error code if feature not supported (-ENOTSUP) or input invalid (-ENODEV). API for e1000 igb driver and vHost driver have been implemented. Other drivers can be implemented over time. Some drivers implement a Tx done flush routine that should be reused where possible. e1000 igb driver and vHost driver do not have such functions. --- v2: * Removed rte_eth_tx_buffer_flush() call and associated parameters from new rte_eth_tx_done_cleanup() API. * Remaining open issue is whether this should be a new API or overload existing rte_eth_tx_buffer() API with input parameter nb_pkts set to 0. My concern is that overloading existing API will not provided enough feedback to application. Application needs to know if feature is supported and driver is attempting to free mbufs or not. * If new API is supported, second open issue is if parameter free_cnt should be included. It was in the original feature request. --- v3: * Removed extra white space in rte_ethdev.h. * Removed inline of new API function in rte_ethdev.h. --- v4: * Added new API to documentation of per nic supported features. --- v5: * Added documentation to the Programmer's Guide. Billy McFall (3): ethdev: new API to free consumed buffers in Tx ring net/e1000: e1000 igb support to free consumed buffers net/vhost: vHost support to free consumed buffers doc/guides/nics/features/default.ini | 1 + doc/guides/nics/features/e1000.ini| 1 + doc/guides/nics/features/vhost.ini| 1 + doc/guides/prog_guide/mempool_lib.rst | 29 drivers/net/e1000/e1000_ethdev.h | 2 + drivers/net/e1000/igb_ethdev.c| 1 + drivers/net/e1000/igb_rxtx.c | 126 ++ drivers/net/vhost/rte_eth_vhost.c | 11 +++ lib/librte_ether/rte_ethdev.c | 14 lib/librte_ether/rte_ethdev.h | 31 + 10 files changed, 217 insertions(+) -- 2.9.3
[dpdk-dev] [PATCH v5 1/3] ethdev: new API to free consumed buffers in Tx ring
Add a new API to force free consumed buffers on Tx ring. API will return
the number of packets freed (0-n) or error code if feature not supported
(-ENOTSUP) or input invalid (-ENODEV).
Signed-off-by: Billy McFall
---
doc/guides/nics/features/default.ini | 1 +
doc/guides/prog_guide/mempool_lib.rst | 29 +
lib/librte_ether/rte_ethdev.c | 14 ++
lib/librte_ether/rte_ethdev.h | 31 +++
4 files changed, 75 insertions(+)
diff --git a/doc/guides/nics/features/default.ini
b/doc/guides/nics/features/default.ini
index 6e4a043..e2d8c83 100644
--- a/doc/guides/nics/features/default.ini
+++ b/doc/guides/nics/features/default.ini
@@ -55,6 +55,7 @@ FW version =
EEPROM dump =
Registers dump =
Multiprocess aware =
+Free TX ring buffers =
BSD nic_uio =
Linux UIO=
Linux VFIO =
diff --git a/doc/guides/prog_guide/mempool_lib.rst
b/doc/guides/prog_guide/mempool_lib.rst
index ffdc109..92c6fd5 100644
--- a/doc/guides/prog_guide/mempool_lib.rst
+++ b/doc/guides/prog_guide/mempool_lib.rst
@@ -132,6 +132,35 @@ These user-owned caches can be explicitly passed to
``rte_mempool_generic_put()`
The ``rte_mempool_default_cache()`` call returns the default internal cache if
any.
In contrast to the default caches, user-owned caches can be used by non-EAL
threads too.
+
+Driver Cache
+
+
+In addition to the a core’s local cache, many of the drivers don't release the
mbuf back to the mempool, or local cache,
+immediately after the packet has been transmitted.
+Instead, they leave the mbuf in their txRing and either perform a bulk release
when the tx_rs_thresh has been crossed
+or free the mbuf when a slot in the txRing is needed.
+
+An application can request the driver to release used mbufs with the
``rte_eth_tx_done_cleanup()`` API.
+This API requests the driver to release mbufs that are no longer in use,
independent of whether or not the tx_rs_thresh
+has been crossed.
+There are two scenarios when an application may want the mbuf back immediately:
+
+* When a given packet needs to be sent to multiple destination interfaces
(either for Layer 2 flooding or Layer 3 multi-cast).
+ One option is to make a copy of the packet or a copy of the header portion
that needs to manipulated.
+ A second option is to transmit the packet and then poll the
``rte_eth_tx_done_cleanup()`` API until the reference count
+ on the packet is decremented.
+ Then the same packet can be transmitted to the next destination interface.
+
+* If an application is designed to make multiple runs, like a packet
generator, and one run has completed.
+ The application may want to reset to a clean state.
+ In this case, it may want to call the ``rte_eth_tx_done_cleanup()`` API to
request each destination interface it has been
+ using to release all of its used mbufs.
+
+To determine if a driver supports this API, check for the *Free TX ring
buffers* feature in the *Network Interface
+Controller Drivers* document.
+
+
Mempool Handlers
diff --git a/lib/librte_ether/rte_ethdev.c b/lib/librte_ether/rte_ethdev.c
index 61f44e2..1cbf6d0 100644
--- a/lib/librte_ether/rte_ethdev.c
+++ b/lib/librte_ether/rte_ethdev.c
@@ -1253,6 +1253,20 @@ rte_eth_tx_buffer_set_err_callback(struct
rte_eth_dev_tx_buffer *buffer,
}
int
+rte_eth_tx_done_cleanup(uint8_t port_id, uint16_t queue_id, uint32_t free_cnt)
+{
+ struct rte_eth_dev *dev = &rte_eth_devices[port_id];
+
+ /* Validate Input Data. Bail if not valid or not supported. */
+ RTE_ETH_VALID_PORTID_OR_ERR_RET(port_id, -ENODEV);
+ RTE_FUNC_PTR_OR_ERR_RET(*dev->dev_ops->tx_done_cleanup, -ENOTSUP);
+
+ /* Call driver to free pending mbufs. */
+ return (*dev->dev_ops->tx_done_cleanup)(dev->data->tx_queues[queue_id],
+ free_cnt);
+}
+
+int
rte_eth_tx_buffer_init(struct rte_eth_dev_tx_buffer *buffer, uint16_t size)
{
int ret = 0;
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index c17bbda..b23886c 100644
--- a/lib/librte_ether/rte_ethdev.h
+++ b/lib/librte_ether/rte_ethdev.h
@@ -1183,6 +1183,9 @@ typedef int (*eth_fw_version_get_t)(struct rte_eth_dev
*dev,
char *fw_version, size_t fw_size);
/**< @internal Get firmware information of an Ethernet device. */
+typedef int (*eth_tx_done_cleanup_t)(void *txq, uint32_t free_cnt);
+/**< @internal Force mbufs to be from TX ring. */
+
typedef void (*eth_rxq_info_get_t)(struct rte_eth_dev *dev,
uint16_t rx_queue_id, struct rte_eth_rxq_info *qinfo);
@@ -1487,6 +1490,7 @@ struct eth_dev_ops {
eth_rx_disable_intr_t rx_queue_intr_disable; /**< Disable Rx queue
interrupt. */
eth_tx_queue_setup_t tx_queue_setup;/**< Set up device TX queue.
*/
eth_queue_release_ttx_queue_release; /**< Release TX queue. */
[dpdk-dev] [PATCH v5 2/3] net/e1000: e1000 igb support to free consumed buffers
Add support to the e1000 igb driver for the new API to force free
consumed buffers on Tx ring. e1000 igb driver does not implement a
tx_rs_thresh to free mbufs, it frees a slot in the ring as needed, so
a new function needed to be written.
Signed-off-by: Billy McFall
---
doc/guides/nics/features/e1000.ini | 1 +
drivers/net/e1000/e1000_ethdev.h | 2 +
drivers/net/e1000/igb_ethdev.c | 1 +
drivers/net/e1000/igb_rxtx.c | 126 +
4 files changed, 130 insertions(+)
diff --git a/doc/guides/nics/features/e1000.ini
b/doc/guides/nics/features/e1000.ini
index 7f6d55c..d4dc7e5 100644
--- a/doc/guides/nics/features/e1000.ini
+++ b/doc/guides/nics/features/e1000.ini
@@ -21,6 +21,7 @@ QinQ offload = Y
L3 checksum offload = Y
L4 checksum offload = Y
Basic stats = Y
+Free TX ring buffers = Y
BSD nic_uio = Y
Linux UIO= Y
Linux VFIO = Y
diff --git a/drivers/net/e1000/e1000_ethdev.h b/drivers/net/e1000/e1000_ethdev.h
index 81a6dbb..39b2f43 100644
--- a/drivers/net/e1000/e1000_ethdev.h
+++ b/drivers/net/e1000/e1000_ethdev.h
@@ -315,6 +315,8 @@ int eth_igb_tx_queue_setup(struct rte_eth_dev *dev,
uint16_t tx_queue_id,
uint16_t nb_tx_desc, unsigned int socket_id,
const struct rte_eth_txconf *tx_conf);
+int eth_igb_tx_done_cleanup(void *txq, uint32_t free_cnt);
+
int eth_igb_rx_init(struct rte_eth_dev *dev);
void eth_igb_tx_init(struct rte_eth_dev *dev);
diff --git a/drivers/net/e1000/igb_ethdev.c b/drivers/net/e1000/igb_ethdev.c
index 8843dd1..12a1a30 100644
--- a/drivers/net/e1000/igb_ethdev.c
+++ b/drivers/net/e1000/igb_ethdev.c
@@ -408,6 +408,7 @@ static const struct eth_dev_ops eth_igb_ops = {
.rx_descriptor_done = eth_igb_rx_descriptor_done,
.tx_queue_setup = eth_igb_tx_queue_setup,
.tx_queue_release = eth_igb_tx_queue_release,
+ .tx_done_cleanup = eth_igb_tx_done_cleanup,
.dev_led_on = eth_igb_led_on,
.dev_led_off = eth_igb_led_off,
.flow_ctrl_get= eth_igb_flow_ctrl_get,
diff --git a/drivers/net/e1000/igb_rxtx.c b/drivers/net/e1000/igb_rxtx.c
index 45f3f24..00cd2aa 100644
--- a/drivers/net/e1000/igb_rxtx.c
+++ b/drivers/net/e1000/igb_rxtx.c
@@ -1277,6 +1277,132 @@ eth_igb_tx_queue_release(void *txq)
igb_tx_queue_release(txq);
}
+static int
+igb_tx_done_cleanup(struct igb_tx_queue *txq, uint32_t free_cnt)
+{
+ struct igb_tx_entry *sw_ring;
+ volatile union e1000_adv_tx_desc *txr;
+ uint16_t tx_first; /* First segment analyzed. */
+ uint16_t tx_id;/* Current segment being processed. */
+ uint16_t tx_last; /* Last segment in the current packet. */
+ uint16_t tx_next; /* First segment of the next packet. */
+ int count;
+
+ if (txq != NULL) {
+ count = 0;
+ sw_ring = txq->sw_ring;
+ txr = txq->tx_ring;
+
+ /*
+* tx_tail is the last sent packet on the sw_ring. Goto the end
+* of that packet (the last segment in the packet chain) and
+* then the next segment will be the start of the oldest segment
+* in the sw_ring. This is the first packet that will be
+* attempted to be freed.
+*/
+
+ /* Get last segment in most recently added packet. */
+ tx_first = sw_ring[txq->tx_tail].last_id;
+
+ /* Get the next segment, which is the oldest segment in ring. */
+ tx_first = sw_ring[tx_first].next_id;
+
+ /* Set the current index to the first. */
+ tx_id = tx_first;
+
+ /*
+* Loop through each packet. For each packet, verify that an
+* mbuf exists and that the last segment is free. If so, free
+* it and move on.
+*/
+ while (1) {
+ tx_last = sw_ring[tx_id].last_id;
+
+ if (sw_ring[tx_last].mbuf) {
+ if (txr[tx_last].wb.status &
+ E1000_TXD_STAT_DD) {
+ /*
+* Increment the number of packets
+* freed.
+*/
+ count++;
+
+ /* Get the start of the next packet. */
+ tx_next = sw_ring[tx_last].next_id;
+
+ /*
+* Loop through all segments in a
+* packet.
+*/
+ do {
+
rte_pktmbuf_free_seg(sw_rin
[dpdk-dev] [PATCH v5 3/3] net/vhost: vHost support to free consumed buffers
Add support to the vHostdriver for the new API to force free consumed
buffers on Tx ring. vHost does not cache the mbufs so there is no work
to do.
Signed-off-by: Billy McFall
---
doc/guides/nics/features/vhost.ini | 1 +
drivers/net/vhost/rte_eth_vhost.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a/doc/guides/nics/features/vhost.ini
b/doc/guides/nics/features/vhost.ini
index 23166fb..83fea03 100644
--- a/doc/guides/nics/features/vhost.ini
+++ b/doc/guides/nics/features/vhost.ini
@@ -9,5 +9,6 @@ Link status event= Y
Queue status event = Y
Basic stats = Y
Extended stats = Y
+Free TX ring buffers = Y
x86-32 = Y
x86-64 = Y
diff --git a/drivers/net/vhost/rte_eth_vhost.c
b/drivers/net/vhost/rte_eth_vhost.c
index 848a3da..6674536 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -934,6 +934,16 @@ eth_queue_release(void *q)
}
static int
+eth_tx_done_cleanup(void *txq __rte_unused, uint32_t free_cnt __rte_unused)
+{
+ /*
+* vHost does not hang onto mbuf. eth_vhost_tx() copies packet data
+* and releases mbuf, so nothing to cleanup.
+*/
+ return 0;
+}
+
+static int
eth_link_update(struct rte_eth_dev *dev __rte_unused,
int wait_to_complete __rte_unused)
{
@@ -974,6 +984,7 @@ static const struct eth_dev_ops ops = {
.tx_queue_setup = eth_tx_queue_setup,
.rx_queue_release = eth_queue_release,
.tx_queue_release = eth_queue_release,
+ .tx_done_cleanup = eth_tx_done_cleanup,
.link_update = eth_link_update,
.stats_get = eth_stats_get,
.stats_reset = eth_stats_reset,
--
2.9.3
Re: [dpdk-dev] [PATCH] net/enic: fix MAC address add and remove
> -Original Message-
> From: Ferruh Yigit [mailto:ferruh.yi...@intel.com]
> Sent: Friday, January 27, 2017 3:07 AM
> To: John Daley (johndale)
> Cc: dev@dpdk.org
> Subject: Re: [PATCH] net/enic: fix MAC address add and remove
>
> On 1/26/2017 8:12 PM, John Daley wrote:
> > The mac_addr_add callback function was simply replacing the primary
> > MAC address instead of adding new ones and the mac_addr_remove
> > callback would only remove the primary MAC form the adapter. Fix the
> > functions to add or remove new address. Allow up to 64 MAC addresses
> per port.
> >
> > Fixes: fefed3d1e62c ("enic: new driver")
> >
> > Signed-off-by: John Daley
> > Reviewed-by: Nelson Escobar
>
> Applied to dpdk-next-net/master, thanks.
>
> (Since it is controversial that if this patch is a fix or implementing a
> missing
> feature (allow up to 64 MAC), I am getting patch as it is, but not CC'ed to
> stable tree, please shout if you disagree.)
That's fine to not put it on stable. Thank you for applying.
-john
[dpdk-dev] rte_eth_from_rings
Hi, I am trying to write a data path for packets punted to CPU(slowpath) from vender silicon like broadcom. I am planing to use "rte_eth_from_rings" like model where I will be able to read and write to the ring for the packets punted from vendor chip. the eth_dev abstraction provided by "rte_eth_from_rings" helps to build the dpdk data path. Can someone help me on how to read and write to the rings that is emulating the eth_dev. Thanks, Sridhar
[dpdk-dev] SIOCSIFFLAGS: Timer expired
Hi , I am creating KNI interface and getting the following error when trying to config IP address. rte_kni_init rte_kni_alloc rte_kni_register_handlers all went through fine. the call back reg for if UP/down is never getting called. What am i missing ? ** the eth_dev here is created with "rte_eth_from_rings". does that make a diff ? Thanks Sridhar root@ VM snaproute/softpath (master) > root@ VM snaproute/softpath (master) >ifconfig PORT_1 PORT_1Link encap:Ethernet HWaddr b6:ed:65:c0:74:70 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@ VM snaproute/softpath (master) >ifconfig PORT_1 up SIOCSIFFLAGS: Timer expired root@ VM snaproute/softpath (master) > root@ VM snaproute/softpath (master) >
[dpdk-dev] [RFC 17.05 v1 0/3] Merge l3fwd-acl and l3fwd
Thanks to Konstantin and Bruce on first internal review comments. This patch is RFC for 17.05 to merge l3fwd-acl and l3fwd code and add file read options to build LPM and EM tables. Ravi Kerur (3): Merge l3fwd-acl and l3fwd LPM config file read option EM config file read option examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 92 ++ examples/l3fwd/l3fwd_acl.c| 1029 ++ examples/l3fwd/l3fwd_acl.h| 234 + examples/l3fwd/l3fwd_acl_scalar.h | 181 examples/l3fwd/l3fwd_em.c | 390 +-- examples/l3fwd/l3fwd_lpm.c| 322 -- examples/l3fwd/main.c | 231 +++-- 10 files changed, 2275 insertions(+), 2341 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h -- 2.7.4
[dpdk-dev] [RFC 17.05 v1 1/3] Merge l3fwd-acl and l3fwd
v1: l3fwd-acl changes: > Merge common init code in l3fwd-acl and l3fwd into main.c. > Move non-critical inline functions to l3fwd_acl.h. > Move critial packet processing inline functions to l3fwd_acl_scalar.h > Move l3fwd-acl init code to l3fwd_acl.c. > Delete l3fwd-acl directory. l3fwd changes: > Add '-A' as an option for ACL processing. > Merge parsing options from l3fwd-acl and l3fwd. Retain l3fwd-acl definitions. > Move specific setup functions (setup_acl, setup_lpm and setup_hash). Testing: Compiled successfully for x86_64-native-linuxapp-gcc Tested LPM, EM and ACL basic functionality. Signed-off-by: Ravi Kerur --- examples/l3fwd-acl/Makefile | 56 - examples/l3fwd-acl/main.c | 2079 - examples/l3fwd/Makefile |2 +- examples/l3fwd/l3fwd.h| 49 + examples/l3fwd/l3fwd_acl.c| 1060 +++ examples/l3fwd/l3fwd_acl.h| 263 + examples/l3fwd/l3fwd_acl_scalar.h | 181 examples/l3fwd/l3fwd_em.c | 14 +- examples/l3fwd/l3fwd_lpm.c| 23 +- examples/l3fwd/main.c | 208 ++-- 10 files changed, 1715 insertions(+), 2220 deletions(-) delete mode 100644 examples/l3fwd-acl/Makefile delete mode 100644 examples/l3fwd-acl/main.c create mode 100644 examples/l3fwd/l3fwd_acl.c create mode 100644 examples/l3fwd/l3fwd_acl.h create mode 100644 examples/l3fwd/l3fwd_acl_scalar.h diff --git a/examples/l3fwd-acl/Makefile b/examples/l3fwd-acl/Makefile deleted file mode 100644 index a3473a8..000 --- a/examples/l3fwd-acl/Makefile +++ /dev/null @@ -1,56 +0,0 @@ -# BSD LICENSE -# -# Copyright(c) 2010-2014 Intel Corporation. All rights reserved. -# All rights reserved. -# -# Redistribution and use in source and binary forms, with or without -# modification, are permitted provided that the following conditions -# are met: -# -# * Redistributions of source code must retain the above copyright -# notice, this list of conditions and the following disclaimer. -# * Redistributions in binary form must reproduce the above copyright -# notice, this list of conditions and the following disclaimer in -# the documentation and/or other materials provided with the -# distribution. -# * Neither the name of Intel Corporation nor the names of its -# contributors may be used to endorse or promote products derived -# from this software without specific prior written permission. -# -# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS -# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT -# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR -# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT -# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, -# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT -# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY -# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT -# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE -# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -ifeq ($(RTE_SDK),) -$(error "Please define RTE_SDK environment variable") -endif - -# Default target, can be overriden by command line or environment -RTE_TARGET ?= x86_64-native-linuxapp-gcc - -include $(RTE_SDK)/mk/rte.vars.mk - -# binary name -APP = l3fwd-acl - -# all source are stored in SRCS-y -SRCS-y := main.c - -CFLAGS += -O3 -CFLAGS += $(WERROR_FLAGS) - -# workaround for a gcc bug with noreturn attribute -# http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12603 -ifeq ($(CONFIG_RTE_TOOLCHAIN_GCC),y) -CFLAGS_main.o += -Wno-return-type -endif - -include $(RTE_SDK)/mk/rte.extapp.mk diff --git a/examples/l3fwd-acl/main.c b/examples/l3fwd-acl/main.c deleted file mode 100644 index 3cfbb40..000 --- a/examples/l3fwd-acl/main.c +++ /dev/null @@ -1,2079 +0,0 @@ -/*- - * BSD LICENSE - * - * Copyright(c) 2010-2016 Intel Corporation. All rights reserved. - * All rights reserved. - * - * Redistribution and use in source and binary forms, with or without - * modification, are permitted provided that the following conditions - * are met: - * - * * Redistributions of source code must retain the above copyright - * notice, this list of conditions and the following disclaimer. - * * Redistributions in binary form must reproduce the above copyright - * notice, this list of conditions and the following disclaimer in - * the documentation and/or other materials pro
[dpdk-dev] [RFC 17.05 v1 3/3] EM config file read option
v1:
> Remove static array configuration of Dest IP,Src IP, Dest
port, Src port, Proto and IF_OUT for EM and EM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#EM route entries,
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
E101.0.0.0 100.10.0.0 101 11 0x06 0
E201.0.0.0 200.20.0.0 102 12 0x06 1
E111.0.0.0 211.30.0.0 101 11 0x06 2
...
#EM6 route entries
#Dest-IP Src-IP Dest-port Src-port Proto IF_OUT
Efe80::::021e:67ff:fe00:
fe80::::021b:21ff:fe91:3805 101 11 0x06 0
Efe90::::021e:67ff:fe00:
fe90::::021b:21ff:fe91:3805 102 12 0x06 1
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd_em.c | 376 +-
1 file changed, 303 insertions(+), 73 deletions(-)
diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
index 6fdabf7..3528947 100644
--- a/examples/l3fwd/l3fwd_em.c
+++ b/examples/l3fwd/l3fwd_em.c
@@ -95,8 +95,14 @@ union ipv4_5tuple_host {
#define XMM_NUM_IN_IPV6_5TUPLE 3
struct ipv6_5tuple {
- uint8_t ip_dst[IPV6_ADDR_LEN];
- uint8_t ip_src[IPV6_ADDR_LEN];
+ union {
+ uint8_t ip_dst[IPV6_ADDR_LEN];
+ uint32_t ip32_dst[4];
+ };
+ union {
+ uint8_t ip_src[IPV6_ADDR_LEN];
+ uint32_t ip32_src[4];
+ };
uint16_t port_dst;
uint16_t port_src;
uint8_t proto;
@@ -116,47 +122,24 @@ union ipv6_5tuple_host {
xmm_t xmm[XMM_NUM_IN_IPV6_5TUPLE];
};
-
-
-struct ipv4_l3fwd_em_route {
- struct ipv4_5tuple key;
- uint8_t if_out;
+enum {
+ CB_FLD_DST_ADDR,
+ CB_FLD_SRC_ADDR,
+ CB_FLD_DST_PORT,
+ CB_FLD_SRC_PORT,
+ CB_FLD_PROTO,
+ CB_FLD_IF_OUT,
+ CB_FLD_MAX
};
-struct ipv6_l3fwd_em_route {
- struct ipv6_5tuple key;
+struct em_rule {
+ union {
+ struct ipv4_5tuple v4_key;
+ struct ipv6_5tuple v6_key;
+ };
uint8_t if_out;
};
-static struct ipv4_l3fwd_em_route ipv4_l3fwd_em_route_array[] = {
- {{IPv4(101, 0, 0, 0), IPv4(100, 10, 0, 1), 101, 11, IPPROTO_TCP}, 0},
- {{IPv4(201, 0, 0, 0), IPv4(200, 20, 0, 1), 102, 12, IPPROTO_TCP}, 1},
- {{IPv4(111, 0, 0, 0), IPv4(100, 30, 0, 1), 101, 11, IPPROTO_TCP}, 2},
- {{IPv4(211, 0, 0, 0), IPv4(200, 40, 0, 1), 102, 12, IPPROTO_TCP}, 3},
-};
-
-static struct ipv6_l3fwd_em_route ipv6_l3fwd_em_route_array[] = {
- {{
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x80, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 0},
-
- {{
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0x90, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 1},
-
- {{
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xa0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 101, 11, IPPROTO_TCP}, 2},
-
- {{
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1e, 0x67, 0xff, 0xfe, 0, 0, 0},
- {0xfe, 0xb0, 0, 0, 0, 0, 0, 0, 0x02, 0x1b, 0x21, 0xff, 0xfe, 0x91,
0x38, 0x05},
- 102, 12, IPPROTO_TCP}, 3},
-};
-
struct rte_hash *ipv4_l3fwd_em_lookup_struct[NB_SOCKETS];
struct rte_hash *ipv6_l3fwd_em_lookup_struct[NB_SOCKETS];
@@ -233,12 +216,6 @@ ipv6_hash_crc(const void *data, __rte_unused uint32_t
data_len,
return init_val;
}
-#define IPV4_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv4_l3fwd_em_route_array) /
sizeof(ipv4_l3fwd_em_route_array[0]))
-
-#define IPV6_L3FWD_EM_NUM_ROUTES \
- (sizeof(ipv6_l3fwd_em_route_array) /
sizeof(ipv6_l3fwd_em_route_array[0]))
-
static uint8_t ipv4_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
static uint8_t ipv6_l3fwd_out_if[L3FWD_HASH_ENTRIES] __rte_cache_aligned;
@@ -338,6 +315,224 @@ em_get_ipv6_dst_port(void *ipv6_hdr, uint8_t portid,
void *lookup_struct)
#include "l3fwd_em.h"
#endif
+static int
+em_parse_v6_addr(const char *in, const char **end, uint32_t v[IPV6_ADDR_U32],
+ char dlm)
+{
+ uint32_t addr[IPV6_ADDR_U16];
+
+ GET_CB_FIELD(in, addr[0], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[1], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[2], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[3], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[4], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[5], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[6], 16, UINT16_MAX, ':');
+ GET_CB_FIELD(in, addr[7], 16, UINT16_MAX, dlm);
+
[dpdk-dev] [RFC 17.05 v1 2/3] LPM config file read option
v1:
> Remove static array configuration of Destination IP, MASK
and IF_OUT for LPM and LPM6 config.
> Add reading configuration from a file.
> Format of configuration file is as follows
#LPM route entries Dest-IP/Mask IF_OUT
L1.1.1.0/24 0
L2.1.1.0/24 1
L3.1.1.0/24 2
...
#LPM6 route entries Dest-IP/Mask IF_OUT
L:::::::/48 0
L2111:::::::/48 1
L3111:::::::/48 2
...
Signed-off-by: Ravi Kerur
---
examples/l3fwd/l3fwd.h | 43 +++
examples/l3fwd/l3fwd_acl.c | 39 +-
examples/l3fwd/l3fwd_acl.h | 29 -
examples/l3fwd/l3fwd_lpm.c | 307 +
examples/l3fwd/main.c | 29 -
5 files changed, 328 insertions(+), 119 deletions(-)
diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h
index 93e08f6..4b1cdc8 100644
--- a/examples/l3fwd/l3fwd.h
+++ b/examples/l3fwd/l3fwd.h
@@ -94,6 +94,47 @@
#define ACL_LEAD_CHAR ('@')
#define ROUTE_LEAD_CHAR('R')
#define COMMENT_LEAD_CHAR ('#')
+#define LPM_LEAD_CHAR ('L')
+#define EM_LEAD_CHAR ('E')
+
+#defineIPV6_ADDR_LEN 16
+#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
+#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
+
+#define GET_CB_FIELD(in, fd, base, lim, dlm) do {\
+ unsigned long val; \
+ char *end; \
+ errno = 0; \
+ val = strtoul((in), &end, (base)); \
+ if (errno != 0 || end[0] != (dlm) || val > (lim)) \
+ return -EINVAL; \
+ (fd) = (typeof(fd))val; \
+ (in) = end + 1; \
+} while (0)
+
+/* Bypass comment and empty lines */
+static inline int
+is_bypass_line(char *buff)
+{
+ int i = 0;
+
+ /* comment line */
+ if (buff[0] == COMMENT_LEAD_CHAR)
+ return 1;
+ /* empty line */
+ while (buff[i] != '\0') {
+ if (!isspace(buff[i]))
+ return 0;
+ i++;
+ }
+ return 1;
+}
+
+struct parm_cfg {
+ const char *rule_ipv4_name;
+ const char *rule_ipv6_name;
+ int scalar;
+};
struct mbuf_table {
uint16_t len;
@@ -134,6 +175,8 @@ extern xmm_t val_eth[RTE_MAX_ETHPORTS];
extern struct lcore_conf lcore_conf[RTE_MAX_LCORE];
+extern struct parm_cfg parm_config;
+
extern int numa_on; /**< NUMA is enabled by default. */
/* Send burst of packets on an output interface */
diff --git a/examples/l3fwd/l3fwd_acl.c b/examples/l3fwd/l3fwd_acl.c
index 977ca05..d6b15d6 100644
--- a/examples/l3fwd/l3fwd_acl.c
+++ b/examples/l3fwd/l3fwd_acl.c
@@ -147,10 +147,6 @@ struct rte_acl_field_def ipv4_defs[NUM_FIELDS_IPV4] = {
},
};
-#defineIPV6_ADDR_LEN 16
-#defineIPV6_ADDR_U16 (IPV6_ADDR_LEN / sizeof(uint16_t))
-#defineIPV6_ADDR_U32 (IPV6_ADDR_LEN / sizeof(uint32_t))
-
enum {
PROTO_FIELD_IPV6,
SRC1_FIELD_IPV6,
@@ -297,12 +293,6 @@ static struct {
const char cb_port_delim[] = ":";
-static struct {
- const char *rule_ipv4_name;
- const char *rule_ipv6_name;
- int scalar;
-} parm_config;
-
/*
* Print and dump ACL/Route rules functions are defined in
* following header file.
@@ -316,27 +306,6 @@ static struct {
#include "l3fwd_acl_scalar.h"
/*
- * API's called during initialization to setup ACL rules.
- */
-void
-l3fwd_acl_set_rule_ipv4_name(const char *optarg)
-{
- parm_config.rule_ipv4_name = optarg;
-}
-
-void
-l3fwd_acl_set_rule_ipv6_name(const char *optarg)
-{
- parm_config.rule_ipv6_name = optarg;
-}
-
-void
-l3fwd_acl_set_scalar(void)
-{
- parm_config.scalar = 1;
-}
-
-/*
* Parses IPV6 address, exepcts the following format:
* ::::::: (where X - is a hexedecimal digit).
*/
@@ -566,7 +535,7 @@ parse_cb_ipv4vlan_rule(char *str, struct rte_acl_rule *v,
int has_userdata)
}
static int
-add_rules(const char *rule_path,
+acl_add_rules(const char *rule_path,
struct rte_acl_rule **proute_base,
unsigned int *proute_num,
struct rte_acl_rule **pacl_base,
@@ -762,8 +731,8 @@ setup_acl(const int socket_id __attribute__((unused)))
dump_acl_config();
- /* Load rules from the input file */
- if (add_rules(parm_config.rule_ipv4_name, &route_base_ipv4,
+ /* Load rules from the input file */
+ if (acl_add_rules(parm_config.rule_ipv4_name, &route_base_ipv4,
&route
Re: [dpdk-dev] rte_eth_from_rings
On Fri, Jan 27, 2017 at 07:16:25PM +, Sridhar Pitchai wrote: > Hi, > > I am trying to write a data path for packets punted to CPU(slowpath) from > vender silicon like broadcom. I am planing to use "rte_eth_from_rings" like > model where I will be able to read and write to the ring for the packets > punted from vendor chip. > > > the eth_dev abstraction provided by "rte_eth_from_rings" helps to build the > dpdk data path. Can someone help me on how to read and write to the rings > that is emulating the eth_dev. > > To use the rings like an ethdev just use rte_eth_rx_burst and rte_eth_tx_burst, passing in the port id of your newly created rings ethdev. To access them directly as rings, just use the ring enqueue/dequeue functions passing in the ring pointer as normal. Regards, /Bruce
Re: [dpdk-dev] rte_eth_from_rings
Thanks Bruce. I have created eth_dev from the rings as below. rt = rte_eth_from_rings(port_p->name, (struct rte_ring * const*)port_p->rx_ring_p, 2, (struct rte_ring * const*)port_p->tx_ring_p, 2, rte_socket_id()); Lets say I have a call back something like pkt_rx(void * pkt_p, struct pkt_metadata_t *meta_p) which is called when there is a pkt at the chip. inside this function(pkt_rx) i will find the port and the corresponding ring_p and enqueue the pkt into the queue. I am assuming this should work. Kindly correct me if i misunderstood you. question 2: Can use this eth_dev to create KNI interface, like below. rte_eth_dev_info_get(fp_p->port_list[port].key.port_id, &dev_info); ; ; ; ops.port_id = fp_p->port_list[port].key.port_id; // rt from rte_eth_from_rings(...) ops.change_mtu = _kni_ifconfig_mtu; // static function ops.config_network_if = _kni_ifconfig; // static functions PORT(fp_p, port).kni_p = rte_kni_alloc(PORT(fp_p, port).mbuf_p, &conf, &ops); I am assuming this should work as well. I find the netdevs created but when i try to configure them i am facing the following error. root@ VM snaproute/softpath (master) >ifconfig PORT_8 PORT_8Link encap:Ethernet HWaddr be:35:c3:0f:f8:2f BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) root@ VM snaproute/softpath (master) >ifconfig PORT_8 20.1.1.1/24 up SIOCSIFFLAGS: Timer expired SIOCSIFFLAGS: Timer expired root@ VM snaproute/softpath (master) > Thanks for the help. Thanks, Sridhar Pitchai From: Bruce Richardson Sent: Friday, January 27, 2017 1:36 PM To: Sridhar Pitchai Cc: dev@dpdk.org Subject: Re: [dpdk-dev] rte_eth_from_rings On Fri, Jan 27, 2017 at 07:16:25PM +, Sridhar Pitchai wrote: > Hi, > > I am trying to write a data path for packets punted to CPU(slowpath) from > vender silicon like broadcom. I am planing to use "rte_eth_from_rings" like > model where I will be able to read and write to the ring for the packets > punted from vendor chip. > > > the eth_dev abstraction provided by "rte_eth_from_rings" helps to build the > dpdk data path. Can someone help me on how to read and write to the rings > that is emulating the eth_dev. > > To use the rings like an ethdev just use rte_eth_rx_burst and rte_eth_tx_burst, passing in the port id of your newly created rings ethdev. To access them directly as rings, just use the ring enqueue/dequeue functions passing in the ring pointer as normal. Regards, /Bruce
