Re: [dpdk-dev] [PATCH] app/testpmd: fix compilation when bitrate lib is disabled
06/05/2017 03:00, Wu, Jingjing:
> From: De Lara Guarch, Pablo
> >
> > Fixes: e25e6c70fb56 ("app/testpmd: add --bitrate-stats option")
> >
> > Signed-off-by: Pablo de Lara
> Acked-by: Jingjing Wu
Applied, thanks
[dpdk-dev] [PATCH v2] mbuf: fix bulk allocation when debug enabled
The debug assertions when allocating a raw mbuf are not correct since
commit 8f094a9ac5d7 ("mbuf: set mbuf fields while in pool"),
which triggers a panic when using this function in debug mode
Signed-off-by: Gregory Etelson
---
lib/librte_mbuf/rte_mbuf.h | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 9097f18..05b8300 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -788,6 +788,13 @@ rte_mbuf_refcnt_set(struct rte_mbuf *m, uint16_t new_value)
void
rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header);
+#define MBUF_RAW_ALLOC_CHECK(m_) do { \
+ RTE_ASSERT(rte_mbuf_refcnt_read(m_) == 1); \
+ RTE_ASSERT(m_->next == NULL); \
+ RTE_ASSERT(m_->nb_segs == 1); \
+ __rte_mbuf_sanity_check(m_, 0); \
+} while (0)
+
/**
* Allocate an unitialized mbuf from mempool *mp*.
*
@@ -815,11 +822,7 @@ static inline struct rte_mbuf *rte_mbuf_raw_alloc(struct
rte_mempool *mp)
if (rte_mempool_get(mp, &mb) < 0)
return NULL;
m = (struct rte_mbuf *)mb;
- RTE_ASSERT(rte_mbuf_refcnt_read(m) == 1);
- RTE_ASSERT(m->next == NULL);
- RTE_ASSERT(m->nb_segs == 1);
- __rte_mbuf_sanity_check(m, 0);
-
+ MBUF_RAW_ALLOC_CHECK(m);
return m;
}
@@ -1152,26 +1155,22 @@ static inline int rte_pktmbuf_alloc_bulk(struct
rte_mempool *pool,
switch (count % 4) {
case 0:
while (idx != count) {
- RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
- rte_mbuf_refcnt_set(mbufs[idx], 1);
+ MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 3:
- RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
- rte_mbuf_refcnt_set(mbufs[idx], 1);
+ MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 2:
- RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
- rte_mbuf_refcnt_set(mbufs[idx], 1);
+ MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
case 1:
- RTE_ASSERT(rte_mbuf_refcnt_read(mbufs[idx]) == 0);
- rte_mbuf_refcnt_set(mbufs[idx], 1);
+ MBUF_RAW_ALLOC_CHECK(mbufs[idx]);
rte_pktmbuf_reset(mbufs[idx]);
idx++;
/* fall-through */
--
2.9.3
Re: [dpdk-dev] [PATCH v2] app/testpmd: disable latency stats by default
06/05/2017 03:10, Wu, Jingjing: > > From: De Lara Guarch, Pablo > > > > Disable latency stats gathering by default, so there is not performance > > degradation if user is not interested in them. > > > > Signed-off-by: Pablo de Lara > Acked-by: Jingjing Wu Applied, thanks
Re: [dpdk-dev] [PATCH 2/2] app/testpmd: fix MAC endian issue in flow command
04/05/2017 19:08, Adrien Mazarguil:
> MAC addresses are implicitly handled in network order since they are
> actually byte strings, however this is not properly enforced with MAC masks
> provided as prefix lengths, which end up inverted on little endian
> systems.
>
> Fixes: 6df81b325fa4 ("app/testpmd: add items eth/vlan to flow command")
>
> Signed-off-by: Adrien Mazarguil
Series applies, thanks
Re: [dpdk-dev] [PATCH v5] app/testpmd: fix port_numa and ring_numa not initialize issue
06/05/2017 02:52, Wu, Jingjing:
> From: Pei, Yulong
> >
> > Previous numa_support = 0 by default, it need to add --numa to testpmd
> > command line to enable numa, so port_numa and ring_numa were initialized at
> > function launch_args_parse(), now testpmd change numa_support = 1 as
> > default,
> > so port_numa and ring_numa also need to initialize by default, otherwise
> > port-
> > >socket_id will be probed to wrong value.
> >
> > Fixes: 999b2ee0fe45 ("app/testpmd: enable NUMA support by default")
> >
> > Signed-off-by: Yulong Pei
> Acked-by: Jingjing Wu
Applied, thanks
Re: [dpdk-dev] [PATCH v3] app/testpmd: configure event display
06/05/2017 02:57, Wu, Jingjing:
> From: Gaetan Rivet [mailto:gaetan.ri...@6wind.com]
> >
> > Add two parameters to testpmd:
> >
> > --print-event
> > --mask-event
> >
> > To enable or disable to printing of events. This display is configured on a
> > per-
> > event basis. By default, all except VF_MBOX are displayed.
> >
> > Fixes: 76ad4a2d82d4 ("app/testpmd: add generic event handler")
> > Cc: "Lu, Wenzhuo"
> >
> > Signed-off-by: Gaetan Rivet
> Acked-by: Jingjing Wu
Applied, thanks
> With minor comments:
>
> Can we add one option "all" like
> print-event=all and mask-event=all to enable/disable all print?
Re: [dpdk-dev] [PATCH v1 1/1] app/procinfo: buffer null termination fix.
21/04/2017 17:06, Roman Korynkevych:
> Coverity issue: 143252
> Fixes: 2deb6b5246d7706448d070335b329d1acb754cee ("app/procinfo: add collectd
> format and host id")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Roman Korynkevych
> ---
> app/proc_info/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/app/proc_info/main.c b/app/proc_info/main.c
> index 16b27b2..97d0352 100644
> --- a/app/proc_info/main.c
> +++ b/app/proc_info/main.c
> @@ -189,7 +189,7 @@ proc_info_preparse_args(int argc, char **argv)
> proc_info_usage(prgname);
> return -1;
> }
> - strncpy(host_id, argv[i+1], sizeof(host_id));
> + strncpy(host_id, argv[i+1], sizeof(host_id)-1);
The full array size should be given to strncpy.
However, the call to gethostname below seems wrong as
it does not use the full size.
Maryam, Reshma,
Please review the procinfo patches.
Re: [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to inject packets
-Original Message- > Date: Fri, 5 May 2017 19:02:59 + > From: "Eads, Gage" > To: Jerin Jacob , "dev@dpdk.org" > > CC: "tho...@monjalon.net" , "Richardson, Bruce" > , "Van Haaren, Harry" > , "hemant.agra...@nxp.com" > , "nipun.gu...@nxp.com" , > "Vangati, Narender" > Subject: RE: [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to > inject packets > > Hi Jerin, Hi Gage, > > > -Original Message- > > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com] > > Sent: Friday, May 5, 2017 8:34 AM > > To: dev@dpdk.org > > Cc: tho...@monjalon.net; Richardson, Bruce ; > > Van Haaren, Harry ; hemant.agra...@nxp.com; > > Eads, Gage ; nipun.gu...@nxp.com; Vangati, > > Narender ; Jerin Jacob > > > > Subject: [dpdk-dev] [PATCH] eventdev: abstract ethdev HW capability to > > inject > > packets > > > > Some Ethdev Hardware is capable of injecting the events(Ethernet packets) > > to > > eventdev without the need for dedicated service cores on Rx path. > > Since eventdev API is device capability agnostic, we need to address three > > combinations of ethdev and eventdev PMD drivers. > > > > 1) Ethdev HW is not capable of injecting the packets and SW eventdev > > driver(All > > existing ethdev PMD + drivers/event/sw PMD combination) > > 2) Ethdev HW is not capable of injecting the packets and not compatible HW > > eventdev driver(All existing ethdev PMD + driver/event/octeontx PMD > > combination) > > 3) Ethdev HW is capable of injecting the packet to compatible HW eventdev > > driver. > > > > This patch abstract such capability disparity and have unified way to get > > the > > functionality in the application. > > > > NOTE: The same infrastructure can be used _if_ an SW PMD wish to create the > > default producer as service function with the service core scheme in EAL to > > make it completely transparent to the application for the default case. The > > selection of service core enablement can be a vdev argument to SW PMD. > > > > I'm not sure that a vdev argument/arguments is the right way to go for cases > 1 and 2. It'll be rather complicated to specify the service core > configuration per event producer on the command line, and that configuration > can't use runtime information. Yes. I didn't meant service core configuration needs to passed through vdev argument. I meant, only the true/false parameter in vdev command line to enable default producer service function in PMD _if_ a PMD wish to do that way. A PMD can choose to return always FALSE for rte_event_dev_has_producer() as it will have be hook to PMD driver. Since service core proposal, talked only about "PMD" registering the service core functions NOT _applications_, I thought you guys need to move default producer handler in PMD and invoke them through service core infrastructure in application with application selected service core mask. if you think, it always makes sense to return FALSE to rte_event_dev_has_producer() on SW PMD then it is fine. This patch does not dictate to return TRUE and it is completely in PMD control. I can remove NOTE: section in git commit section it is confusing. > > What do you think about this approach: We develop a library of device > producer code, with interfaces designed to run on service cores, that the app > can run if rte_event_dev_has_producer() returns FALSE. The device producer > code would, at minimum, have some configuration function (more or less > equivalent to the rte_event_queue_producer_conf) and a run function that (at > a high level) processes eth/crypto/etc.-dev queues and injects events into an > event device. That fine. > > For example, if rte_event_dev_has_producer() indicates there's no hardware > support for connecting an ethdev to the event device, the application > configures the ethdev->eventdev producer code and installs the run function > with the service core infrastructure. > > Plus, this approach allows an application to plug in their own device > producer logic, if they require some app-specific functionality. In that > case, the DPDK-provided device producer could serve as a template for the app > developer. Make sense. I believe, which is inline with rte_event_dev_has_producer() comment in the patch -- When application needs to setup an event producer to inject the events to eventdev, application must check the event device producer capability by invoking this function, On success, application can configure to inject the events to eventdev by setting up the event queue using rte_event_queue_setup() with checked *conf*. On failure due to lack of adequate capability in PMD or an application that wish to ~~ inject the event through application, it must create additional event port by configuring the eventdev with rte_event_dev_co
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
Hi,
Do we need an explicit "Acked-by" keyword for this
patch to be accepted and applied?
Thanks,
Srini
On Tue, Apr 25, 2017 at 6:53 AM, Lu, Wenzhuo wrote:
> Hi Srini,
>
>
>> -Original Message-
>> From: Srinivasan J [mailto:srinid...@gmail.com]
>> Sent: Monday, April 24, 2017 6:51 PM
>> To: Lu, Wenzhuo
>> Cc: Ananyev, Konstantin; dev@dpdk.org
>> Subject: Re: [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
>>
>> Hi Wenzhuo,
>> Port hot-plug would require the DPDK app to dynamically
>> mange
>> ports and the kernel to support PCI hot-plugging.
>> When multiple ports are detached/attached (SFP's plugged in/out), would
>> the DPDK port id's remain same? If not, app needs to handle port id change
>> for a give NIC.
> Yes, APP needs to handle the port id change. Agree this patch is a much
> simpler solution than the port hot-plug.
> So I don’t object it :)
>
>>
>> While port hot-plug can be used to dynamically handle SFP hot-plugging, I
>> feel it's not the optimal solution.
>>
>> Regards,
>> Srini
>>
>> On Mon, Apr 24, 2017 at 12:45 PM, Lu, Wenzhuo
>> wrote:
>> > Hi Srini,
>> >
>> >
>> >> -Original Message-
>> >> From: Srinivasan J [mailto:srinid...@gmail.com]
>> >> Sent: Monday, April 24, 2017 2:24 PM
>> >> To: Lu, Wenzhuo
>> >> Cc: Ananyev, Konstantin; dev@dpdk.org
>> >> Subject: Re: [PATCH] net/ixgbe: support detection of hot swapped
>> >> SFP/SFP+
>> >>
>> >> Hi Wenzhuo,
>> >>I understand your concern. I had to do this change
>> >> to support hot swap of SFP/SFP+ modules without restarting the DPDK
>> >> app. If we have some other mechanism in pipeline to support hot swap
>> >> of SFP/SFP+ modules, then my changes can be ignored. I just wanted to
>> >> share the changes which worked for me back to the community.
>> > I think restarting the APP is not necessary. You can uninit the port, then
>> re-init the port.
>> > Please reference
>> http://dpdk.org/doc/guides/prog_guide/port_hotplug_framework.html to
>> see if it can help.
>> >
>> >>
>> >> Regards,
>> >> Srini
>> >>
>> >> On Fri, Apr 21, 2017 at 10:22 AM, Lu, Wenzhuo
>> >> wrote:
>> >> > Hi Srini,
>> >> >
>> >> >> -Original Message-
>> >> >> From: Srini J [mailto:srinid...@gmail.com]
>> >> >> Sent: Thursday, April 20, 2017 6:48 PM
>> >> >> To: Lu, Wenzhuo; Ananyev, Konstantin
>> >> >> Cc: dev@dpdk.org; Srinivasan Jayarajan
>> >> >> Subject: [PATCH] net/ixgbe: support detection of hot swapped
>> >> >> SFP/SFP+
>> >> >>
>> >> >> From: Srinivasan Jayarajan
>> >> >>
>> >> >> Adds support to use a different SFP/SFP+ without restarting the
>> >> >> DPDK app. rte_eth_dev_stop()/rte_eth_dev_start() will need
>> >> >> to be called on the port to detect the SFP/SFP+ change.
>> >> >>
>> >> >> Signed-off-by: Srinivasan Jayarajan
>> >> >> ---
>> >> >> drivers/net/ixgbe/ixgbe_ethdev.c | 13 +
>> >> >> 1 file changed, 13 insertions(+)
>> >> >>
>> >> >> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c
>> >> >> b/drivers/net/ixgbe/ixgbe_ethdev.c
>> >> >> index c226e0a..85407a9 100644
>> >> >> --- a/drivers/net/ixgbe/ixgbe_ethdev.c
>> >> >> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c
>> >> >> @@ -2520,6 +2520,19 @@ static int eth_ixgbevf_pci_remove(struct
>> >> >> rte_pci_device *pci_dev)
>> >> >> status = ixgbe_pf_reset_hw(hw);
>> >> >> if (status != 0)
>> >> >> return -1;
>> >> >> +
>> >> >> + /* Set phy type as unknown so that PHY scan is always done */
>> >> >> + hw->phy.type = ixgbe_phy_unknown;
>> >> >> +
>> >> >> + /* Identify PHY and related function pointers */
>> >> >> + status = hw->phy.ops.init(hw);
>> >> >> +
>> >> >> + if (status == IXGBE_ERR_SFP_NOT_SUPPORTED) {
>> >> >> + PMD_INIT_LOG(ERR, "Found unsupported SFP in "
>> >> >> + "ixgbe_dev_start(): %d", status);
>> >> >> + return -1;
>> >> >> + }
>> >> >> +
>> >> > I have the concern if it's a good idea to move the functions from
>> >> > dev_init
>> >> to dev_start. Especially this function named init.
>> >> > Anyway, let's listen to others opinion.
>> >> >
>> >> >
>> >> >> hw->mac.ops.start_hw(hw);
>> >> >> hw->mac.get_link_status = true;
>> >> >>
>> >> >> --
>> >> >> 1.8.1.4
>> >> >
Re: [dpdk-dev] [RFC 17.08] Flow classification library
Carthago delenda est: Again with the callbacks... why not just let the application call the library's processing functions where appropriate. The hook+callback design pattern tends to impose a specific framework (or order of execution) on the DPDK user, rather than just being a stand-alone library offering some functions. DPDK is not a stack; and one of the reasons we are moving our firmware away from Linux is to avoid being enforced a specific order of processing the packets (through a whole bunch of hooks everywhere in the stack). Maybe I missed the point of this library, so bear with me if my example is stupid: Consider a NAT router application. Does this library support processing ingress packets in the outside->inside direction after they have been processed by the NAT engine? Or how about IP fragments after passing the reassembly engine? Generally, a generic flow processing library would be great; but such a library would need to support flow processing applications, not just byte counting. Four key functions would be required: 1. Identify which flow a packet belongs to (or "not found"), 2. Create a flow, 3. Destroy a flow, and 4. Iterate through flows (e.g. for aging or listing purposes). Med venlig hilsen / kind regards - Morten Brørup > -Original Message- > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Mcnamara, John > Sent: Wednesday, May 3, 2017 11:16 AM > To: dev@dpdk.org > Cc: Tahhan, Maryam; Gaëtan Rivet; Yigit, Ferruh > Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library > > > > > -Original Message- > > From: Gaëtan Rivet [mailto:gaetan.ri...@6wind.com] > > Sent: Friday, April 21, 2017 11:38 AM > > To: Yigit, Ferruh > > Cc: dev@dpdk.org; Mcnamara, John ; Tahhan, > > Maryam > > Subject: Re: [dpdk-dev] [RFC 17.08] Flow classification library > > > > > Any other opinions on this proposal? > > (Original email: http://dpdk.org/ml/archives/dev/2017-April/064443.html) > > John
Re: [dpdk-dev] [RFC] service core concept header implementation
-Original Message-
> Date: Fri, 5 May 2017 15:48:02 +
> From: "Van Haaren, Harry"
> To: Jerin Jacob
> CC: "dev@dpdk.org" , "Richardson, Bruce"
> , "hemant.agra...@nxp.com"
> , "nipun.gu...@nxp.com" ,
> "Vangati, Narender" , "Eads, Gage"
>
> Subject: RE: [RFC] service core concept header implementation
>
>
> > From: Jerin Jacob [mailto:jerin.ja...@caviumnetworks.com]
>
> > > Hi Harry,
> > >
> > > Overall it looks good. Some initial comments
>
> Off to a good start! Replies inline, in general I think we're on the same
> page. This RFC was pretty "fresh", mostly to check if the community agrees
> with the general concept of service-cores. The implementation details
> (although going well) will have some churn I expect :)
>
> I'd like opinions from others in the community - I'll leave this thread
> "open" for a while to get more feedback, and rework a v2 RFC then.
>
> Thanks for your review - Harry
>
>
> > >
> > > Regarding step 4 and 5, It looks like,
> > > a) The lcore_id information is duplicate in step 4 and 5.
>
>
> Not really duplicated - keep in mind we do not want to have a 1:1 mapping,
> the goal of this is to allow e.g. 3 cores -> 5 services type mappings, where
> the work is shared between the cores. Hence, setting coremasks and setting
> lcores to use are very related, but not quite the same.
>
>
> > > b) On rte_eal_service_set_coremask() failure, you may the need
> > > inverse of rte_eal_service_use_lcore()(setting back to worker/normal
> > > lcore)
>
> We can pass the "type" of lcore as an argument to a function:
>
> #define RTE_EAL_SERVICE_TYPE_APPLICATION 0
> #define RTE_EAL_SERVICE_TYPE_SERVICE 1
>
> rte_eal_service_set_lcore_type(uint32_t type);
>
> Allows adding more core types (if anybody can think of any) and avoids
> function-count bloat :)
>
>
> > > But I understand the need for step 5.
> > >
> > > How about changing the (4) and (5) as
> > >
> > > step 4) rte_eal_service_set_coremask
> > > step 5) rte_eal_service_apply(void)(or similar name) for error check and
> > > ensure at least on core is going to be running the service.
>
> So the sequence would be:
>
> for( i < app_n_service_cores )
>rte_eal_service_set_lcore_type( SERVICE );
>
> for( i < services_count )
>rte_eal_serivce_set_coremask( app_decided_coremask_here );
I thought, The application may not need to set the explicit
rte_eal_service_set_lcore_type, it can be internally set by
rte_eal_service_set_coremask
i.e
for( i < services_count )
rte_eal_service_set_coremask( app_decided_coremask_here );
int ret = rte_eal_service_apply();
rte_eal_service_set_coremask(app_decided_coremask_here)
{
proposed_implementation;
for_each_bit_set(app_decided_coremask_here)
rte_eal_service_set_lcore_type(SERVICE);
}
>
> int ret = rte_eal_service_apply();
>
> if(ret) {
>/* application can rte_panic(), or reset CPU cores to default APP state
> and continue */
> }
>
> /* application profits from service-cores feature in EAL */
>
> > 2) What would be the tear down sequence of the service core especially when
> > device stop or close happens?
>
> Good question. Being able to "turn off" a single service while keeping other
> services running would be useful I think. That might require some extra
> tracking at the implementation layer, but perhaps something that's worth
> doing. Opinions and use-cases welcome here!
I think it makes sense to add "turn off" support for each service
functions as we are multiplexing the service core.
>
>
>
Re: [dpdk-dev] [PATCH] net/ixgbe: support detection of hot swapped SFP/SFP+
06/05/2017 15:51, Srinivasan J: > Hi, >Do we need an explicit "Acked-by" keyword for this > patch to be accepted and applied? Yes, given it is not a trivial patch, an ack from the maintainer is required. Anyway, it has been submitted too late for 17.05 testing.
[dpdk-dev] [PATCH] app/testpmd: print all or no events
Adds the "all" option to the print-event and mask-event parameters. This
option will enable or disable all event notifications from being
displayed.
Signed-off-by: Gaetan Rivet
Cc: Jingjing Wu
---
app/test-pmd/parameters.c | 10 ++
doc/guides/testpmd_app_ug/run_app.rst | 10 ++
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/app/test-pmd/parameters.c b/app/test-pmd/parameters.c
index 23f2fa3..24ed046 100644
--- a/app/test-pmd/parameters.c
+++ b/app/test-pmd/parameters.c
@@ -206,10 +206,10 @@ usage(char* progname)
printf(" --no-rmv-interrupt: disable device removal interrupt.\n");
printf(" --bitrate-stats=N: set the logical core N to perform "
"bit-rate calculation.\n");
- printf(" --print-event
: "
- "enable print of designated event");
- printf(" --mask-event
: "
- "disable print of designated event");
+ printf(" --print-event
: "
+ "enable print of designated event or all of them.");
+ printf(" --mask-event
: "
+ "disable print of designated event or all of them.");
}
#ifdef RTE_LIBRTE_CMDLINE
@@ -526,6 +526,8 @@ parse_event_printing_config(const char *optarg, int enable)
mask = UINT32_C(1) << RTE_ETH_EVENT_MACSEC;
else if (!strcmp(optarg, "intr_rmv"))
mask = UINT32_C(1) << RTE_ETH_EVENT_INTR_RMV;
+ else if (!strcmp(optarg, "all"))
+ mask = ~UINT32_C(0);
else {
fprintf(stderr, "Invalid event: %s\n", optarg);
return -1;
diff --git a/doc/guides/testpmd_app_ug/run_app.rst
b/doc/guides/testpmd_app_ug/run_app.rst
index 98f6d1f..2a43214 100644
--- a/doc/guides/testpmd_app_ug/run_app.rst
+++ b/doc/guides/testpmd_app_ug/run_app.rst
@@ -478,10 +478,12 @@ The commandline options are:
Set the logical core N to perform bitrate calculation.
-* ``--print-event
``
+* ``--print-event
``
-Enable printing the occurrence of the designated event.
+Enable printing the occurrence of the designated event. Using all will
+enable all of them.
-* ``--mask-event
``
+* ``--mask-event
``
-Disable printing the occurrence of the designated event.
+Disable printing the occurrence of the designated event. Using all will
+disable all of them.
--
2.1.4
Re: [dpdk-dev] [PATCH v7 1/3] ethdev: fix adding invalid MAC addr
On Fri, May 05, 2017 at 04:21:53PM +0200, Thomas Monjalon wrote: > 05/05/2017 02:40, Wei Dai: > > Some customers find adding MAC addr to VF sometimes can fail, > > but it is still stored in dev->data->mac_addrs[ ]. So this > > can lead to some errors that assumes the non-zero entry in > > dev->data->mac_addrs[ ] is valid. > > Following acknowledgements are from specific NIC PMD > > maintainer for their managing part. > > > > This patch changes the ethdev API, it should not be > > backported to a stable/LTS release so far. > > It changes only the internal function pointer used by drivers, > not the API. Oh, right. I was thinking the eth API rte_eth_dev_mac_addr also has to be changed. It turned out that it's already been designed with returning "int". Sorry for the noise. --yliu
Re: [dpdk-dev] [dpdk-stable] [PATCH 11/11] net/qede: fix to limit CFLAGS to base files
> From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> Sent: Wednesday, May 03, 2017 7:11 PM
>
> On Thu, May 04, 2017 at 12:14:30AM +, Mody, Rasesh wrote:
> >
> >
> > > From: Yuanhan Liu [mailto:yuanhan@linux.intel.com]
> > > Sent: Monday, May 01, 2017 11:15 PM
> > >
> > > On Tue, Apr 25, 2017 at 12:28:46AM -0700, Rasesh Mody wrote:
> > > > From: Rasesh Mody
> > > >
> > > > Changes included in this fix
> > > > - limit CFLAGS to base files
> > > > - fix to remove/mark unused members
> > > > - add checks for debug config option
> > > > - make qede_set_mtu() and qede_udp_dst_port_del() static and
> others
> > > >non-static as appropriate
> > > > - move local APIs qede_vlan_offload_set() and
> > > > qede_rx_cqe_to_pkt_type()
> > > > - initialize variables as required
> > >
> > > When there are so many items in one single patch, it basically means
> > > it's done wrongly. Generally, we should make one patch for each item.
> > >
> > > > Fixes: ec94dbc57362 ("qede: add base driver")
> > > > Cc: sta...@dpdk.org
> > >
> > > It's also not a good idea to put "Cc: stable" tag in a huge fix patch.
> > > It's very likely it won't apply cleanly to a stable/LTS release. For
> > > instance, I failed to apply it to 16.11.2 (LTS).
> > >
> > > >
> > > > Signed-off-by: Rasesh Mody
> > > > ---
> > > > drivers/net/qede/Makefile | 32 -
> > > > drivers/net/qede/base/ecore.h |4 +-
> > > > drivers/net/qede/base/ecore_int_api.h |4 +-
> > > > drivers/net/qede/qede_ethdev.c| 120 ++
>
> > > ---
> > > > drivers/net/qede/qede_ethdev.h| 32 -
> > > > drivers/net/qede/qede_fdir.c | 13 +---
> > > > drivers/net/qede/qede_if.h|4 ++
> > > > drivers/net/qede/qede_main.c |8 +--
> > > > drivers/net/qede/qede_rxtx.c | 118 +
> -
> > > --
> > > > 9 files changed, 171 insertions(+), 164 deletions(-)
> > >
> > > It's also a clear sign of bad patch: too many changes for a single bug fix
> patch.
> > >
> > > Most of them look like minor fixes to me. So my question is are
> > > there any important items really should be picked for stable and LTS
> release?
> > > More specifically, do they really fix any (fatal) issues? If no, I
> > > will drop it. If yes, please send a (or some) patch with the real
> > > fixes backported only to stable ML, so that I could pick them.
> >
> > The patch is a Makefile change to restrict the CFLAG only to the base files.
> Once Makefile was changed it exposed few issues with PMD.
>
> In such case, you could make patches to fix those issues first, one patch for
> one issue, and then put the CFLAG change to the last.
>
> > Hence, we thought of putting all the changes in single patch since they
> were relevant changes.
> >
> > As you stated most of them are minor fixes. We'll evaluate the patch if
> anything specifically need to go into the stable release and get back.
>
> Thanks. The answer seems to be "NO" to me though.
We can skip this patch for stable release backport.
Thanks!
-Rasesh
>
> --yliu
Re: [dpdk-dev] [PATCH v2] app/testpmd: support non contiguous socket ids
Saturday, May 6, 2017 4:41 AM, Wu, Jingjing:
> >
> > The test assumes the socket ids are contiguous. This is not
> > necessarily the case on all servers and may cause mempool creation to fail.
> >
> > Fixing it by detecting the list of valid socket ids and use it for the
> > mempool creation.
> >
> > Fixes: 7acf894d07d1 ("app/testpmd: detect numa socket count")
> >
> > CC: sta...@dpdk.org
> > Signed-off-by: Shahaf Shuler
> > ---
> > on v2:
> > * fix minor typo on commit message : be->by.
> > ---
> > app/test-pmd/parameters.c | 38 -
> -
> > app/test-pmd/testpmd.c| 38 +--
> ---
> > app/test-pmd/testpmd.h| 4 +++-
> > 3 files changed, 60 insertions(+), 20 deletions(-)
> >
[..]
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index
> > dfe64427d..a556a8aff 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
[..]
> > +/*
> > * Setup default configuration.
> > */
> > static void
> > @@ -388,12 +405,14 @@ set_default_fwd_lcores_config(void)
> >
> > nb_lc = 0;
> > for (i = 0; i < RTE_MAX_LCORE; i++) {
> > - sock_num = rte_lcore_to_socket_id(i) + 1;
> > - if (sock_num > max_socket) {
> > - if (sock_num > RTE_MAX_NUMA_NODES)
> > - rte_exit(EXIT_FAILURE, "Total sockets
> greater
> > than %u\n", RTE_MAX_NUMA_NODES);
> > - max_socket = sock_num;
> > + sock_num = rte_lcore_to_socket_id(i);
> +1 is missed?
I don't think so.
On previous implementation this logic was meant to find the max_socket.
max_socket was the first invalid socket_id and was used, for example :
if (socket_id >= max_socket) {
or
for (i = 0; i < max_socket; i++)
now, on above logic, we list the valid socket id. Therefore
rte_lcore_to_socket_id return a valid id and not need to add 1.
