<
eimear.morrissey at ie.ibm.com> wrote:
> Arnon Warshavsky wrote on 10/19/2015 03:01:46 PM:
>
> > From: Arnon Warshavsky
> > To: Eimear Morrissey/Ireland/IBM at IBMIE
> > Cc: dev at dpdk.org
> > Date: 10/19/2015 03:01 PM
> > Subject: Re: [dpdk-dev] Inc
.
thanks
/Arnon
On Thu, Oct 22, 2015 at 12:57 PM, Eimear Morrissey <
eimear.morrissey at ie.ibm.com> wrote:
> Arnon Warshavsky wrote on 10/19/2015 03:46:22 PM:
>
> > From: Arnon Warshavsky
> > To: Eimear Morrissey/Ireland/IBM at IBMIE
> > Cc: dev at dpdk.org
t 22, 2015 at 3:48 PM, Eimear Morrissey <
eimear.morrissey at ie.ibm.com> wrote:
> Arnon Warshavsky wrote on 10/22/2015 12:12:47 PM:
>
> > From: Arnon Warshavsky
> > To: Eimear Morrissey/Ireland/IBM at IBMIE
> > Cc: dev at dpdk.org
> > Date: 10/22/2015 12:12
ity_xon_tx[6]: 0
> > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[6]: 0
> > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[6]: 0
> > >>>> PMD: i40e_dev_stats_get(): priority_xon_tx[7]: 0
> > >>>> PMD: i40e_dev_stats_get(): priority_xoff_tx[7]: 0
> > >>>> PMD: i40e_dev_stats_get(): priority_xon_2_xoff[7]: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_64: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_127: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_255: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_511: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_1023: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_size_1522: 16779
> > >>>> PMD: i40e_dev_stats_get(): rx_size_big: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_undersize: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_fragments: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_oversize: 0
> > >>>> PMD: i40e_dev_stats_get(): rx_jabber:0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_64: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_127: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_255: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_511: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_1023: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_1522: 0
> > >>>> PMD: i40e_dev_stats_get(): tx_size_big: 0
> > >>>> PMD: i40e_dev_stats_get(): mac_short_packet_dropped: 0
> > >>>> PMD: i40e_dev_stats_get(): checksum_error: 0
> > >>>> PMD: i40e_dev_stats_get(): fdir_match: 0
> > >>>> PMD: i40e_dev_stats_get(): * PF stats end
> > >>>>
> > >>>> ...
> > >>>>
> > >>>> The count for rx_unicast is exactly the number of packets we would
> > >>>> have expected and the count for rx_discards in the VSI stats is
> > >>>> exactly the number of packets we are missing.
> > >>>> The question is why this number shows up only in the VSI stats and
> > >>>> not in the PF stats and of course why the packets which were
> > >>>> obviously discarded are still counted in the rx_unicast stats.
> > >>>> This test was performed using DPDK 2.1 and the firmware of the
> > >>>> XL710 is the latest one (FW 4.40 API 1.4 NVM 04.05.03).
> > >>>> Do you have an idea what might be going on?
> > >>>>
> > >>>> Best regards,
> > >>>> Martin
> > >>>>
> > >>>>
> >
>
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
On Wed, Jun 1, 2016 at 7:18 PM, Bruce Richardson wrote:
> On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote:
> > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith
> wrote:
> >
> > > Started from the link below, but did not want to highjack the thread.
> > > http://dpdk.org/ml/archives/dev/
On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman wrote:
> On Fri, Jun 03, 2016 at 12:01:30PM +0100, Bruce Richardson wrote:
> > On Fri, Jun 03, 2016 at 11:29:43AM +0100, Bruce Richardson wrote:
> > > On Thu, Jun 02, 2016 at 04:08:37PM -0400, Neil Horman wrote:
> > > > On Thu, Jun 02, 2016 at 07:41:10P
On Fri, Jun 3, 2016 at 3:53 PM, Panu Matilainen wrote:
> On 06/03/2016 03:01 PM, Arnon Warshavsky wrote:
>
>>
>>
>> On Fri, Jun 3, 2016 at 2:50 PM, Neil Horman > <mailto:nhorman at tuxdriver.com>> wrote:
>>
>> On Fri, Jun 03, 2016 at 12:01:30P
On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman wrote:
> On Fri, Jun 03, 2016 at 06:29:13PM +, Wiles, Keith wrote:
> >
> > On 6/3/16, 12:44 PM, "Neil Horman" wrote:
> >
> > >On Fri, Jun 03, 2016 at 04:04:14PM +, Wiles, Keith wrote:
> > >> Sorry, I deleted all of the text as it was getting a
at dpdk.org on behalf of keith.wiles at intel.com> wrote:
> >>
> >> >On 6/3/16, 1:52 PM, "Arnon Warshavsky" arnon at qwilt.com>> wrote:
> >> >
> >> >
> >> >
> >> >On Fri, Jun 3, 2016 at 9:38 PM, Neil Horman <mai
--
> *- Thanks*
> *char * (*shesha) (uint64_t cache, uint8_t F00D)*
> *{ return 0xC0DE; } *
>
> From: Stephen Hemminger
> Date: Monday, November 2, 2015 at 8:24 AM
> To: Arnon Warshavsky
> Cc: Cisco Employee , "dev at dpdk.org"
> Subject: Re: [dpdk-dev] Reshuffling
(*shesha) (uint64_t cache, uint8_t F00D)
> { return 0xC0DE; }
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
anyone tell if the regression tests are comparing performance while
building DPDK with the default set of flags alone, or are multiple options
examined?
2)
How are issues like that being tracked and later associated to a patch?
Thanks
/Arnon
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634
On Tue, Apr 5, 2016 at 5:13 PM, Trahe, Fiona wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Tuesday, April 05, 2016 2:57 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] DPDK namespace
> >
> > DPDK is going to be m
On Fri, Apr 29, 2016 at 9:24 PM, Jay Rolette wrote:
> On Fri, Apr 29, 2016 at 1:16 PM, Don Provan wrote:
>
> > >From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> > >Subject: [dpdk-dev] removing mbuf error flags
> > >
> > >My opinion is that invalid packets should not be given to the
> appl
ot;Warning in " substr(last_file,6) ":"
> + print "Warning in " substr(last_file,7) ":"
> print MESSAGE
> exit RET_ON_FAIL
> }
> --
> 2.23.0
>
>
Acked-By: Arnon Warshavsky
Have rte_eal_config_reattach clean up the mapped address
which is a valid address but not the one intended.
Coverity issue: 343439
Signed-off-by: Arnon Warshavsky
---
lib/librte_eal/linux/eal/eal.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/librte_eal/linux/eal/eal.c b/lib
Have rte_eal_config_reattach clean up the mapped address
which is a valid address but not the one intended.
Coverity issue: 343439
Fixes: 4e8854ae89fa ("eal: do not panic on shared memory init")
Fixes: b149a7064261 ("eal/freebsd: add config reattach in secondary")
Signed-off-
>
>
> What happened to this patchset?
>
> This is definitely an improvement. We must remove rte_panic from libs.
> Arnon, are you still available to rebase this patchset in preparation
> of 19.08? Or someone else?
>
> What are the required API breakages? I see one in ethdev which requires
> a depre
For the purpose of removing instances of rte_panic
from the init sequence, some void functions need to change
to return an error code.The planned modifications of 19.08
require to change one eal function and one kni function.
Signed-off-by: Arnon Warshavsky
---
doc/guides/rel_notes
>
>
> Changing 'kni_fifo_init()' return type shouldn't be a problem at all,
> perhaps it would be a problem if the content of the fifo changed but it is
> not
> the case.
>
Should I move this patch to deferred or reject?
>
>
>
> I am preparing a deprecation notice for rte_eal_remote_launch
> and rte_metrics_init.
>
>
> hmm, I followed panic and not exit, so missed rte_metrics_init.
rte_eal_remote_launch currently returns int. what deprecation goes there?
On Wed, May 8, 2019 at 11:54 PM Thomas Monjalon wrote:
> Two public functions from EAL and metrics libraries need to return
> some new error codes instead of calling rte_panic or rte_exit.
>
> Signed-off-by: Thomas Monjalon
> ---
>
> --
> 2.21.0
>
>
Acked-By: Arnon Warshavsky
Hi, I plan to work on it on the first week of June. Will be pretty much
off-grid till then.
thanks
/Arnon
where the PMDs or message threads
may call panic with no context for the user.
For these I will submit a patch suggesting a callback registration,
allowing the user to register a context to be called
in case of a panic that takes place outside the init sequence.
Signed-off-by: Arnon Warshavsky
where the PMDs or message threads
may call panic with no context for the user.
For these I will submit a patch suggesting a callback registration,
allowing the user to register a context to be called
in case of a panic that takes place outside the init sequence.
Signed-off-by: Arnon Warshavsky
where the PMDs or message threads
may call panic with no context for the user.
For these I will submit a patch suggesting a callback registration,
allowing the user to register a context to be called
in case of a panic that takes place outside the init sequence.
Signed-off-by: Arnon Warshavsky
Hi
>
> The part below can go after a --- marker, this is more a comment for the
> work in progress rather than something to put in this patch commitlog.
>
Ack
>
> The calls for launching core messaging threads were left in tact
>> in all 3 eal implementations.
>>
>
> For these I will submit a p
This patch changes some void functions to return a value,
so that the init sequence may tear down orderly
instead of calling panic.
Signed-off-by: Arnon Warshavsky
---
The calls for launching core messaging threads were left in tact
in all 3 eal implementations.
This should be addressed in a
On Wed, Jun 5, 2019 at 10:50 AM David Marchand
wrote:
>
>
> On Tue, Jun 4, 2019 at 5:45 PM Arnon Warshavsky wrote:
>
>> This patch changes some void functions to return a value,
>> so that the init sequence may tear down orderly
>> instead of calling panic.
&g
This patch changes some void functions to return a value,
so that the init sequence may tear down orderly
instead of calling panic.
Signed-off-by: Arnon Warshavsky
---
The calls for launching core messaging threads were left in tact
in all 3 eal implementations.
This should be addressed in a
201 - 230 of 230 matches
Mail list logo
