g scheme of Year.Month. Should we consider adopting that
> convention? If we move in future to a model where we have long-term support
> releases (something that was touched on in Dublin), then we could append an
> LTS designation to the release number.
>
>
> Tim
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
to have the secondary process then write packets to a
> pcap
> file using a pcap PMD, but down the road if we get other PMDs, like a
> KNI PMD
> or a TAP device PMD, those could be used as targets instead.
>
> This implementation we hope should provide enough hooks to enable the
> standard
> tools to be used for monitoring and capturing packets. We will send out
> draft
> implementation code for various parts of this as soon as we have it.
>
> Additional feedback welcome, as always. :-)
>
> Regards,
> /Bruce
>
>
--
*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.
> > >
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
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
On Wed, Jun 15, 2016 at 4:03 PM, Dumitrescu, Cristian <
cristian.dumitrescu at intel.com> wrote:
>
>
> > -Original Message-
> > From: Yerden Zhumabekov [mailto:e_zhumabekov at sts.kz]
> > Sent: Wednesday, June 15, 2016 1:55 PM
> > To: Dumitrescu, Cristian ; Panu
> Matilainen
> > ; dev at
from the API manual is that the rte_eth_stats q_errors
> array should count the packets missed because software isn't polling fast
> enough, but that doesn't seem to be the case? Is there a standard DPDK way
> to check this? The application is a forwarding one so there's no other way
> t
<
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
*
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
--
> *- 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
esha) (uint64_t cache, uint8_t F00D)
> { return 0xC0DE; }
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
I blindly run the reset command.
>
> Did anybody else try it on a black background? Did anybody else see these
> issues with it as well?
>
> Matthew.
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
used, versions, ?
>
>
> Thanks
> ++Keith
> >
> >If you quit the app it does not reset the colors so my shell is also
> >invisible, until I blindly run the reset command.
> >
> >Did anybody else try it on a black background? Did anybody else see
> >these issues with it as well?
> >
> >Matthew.
> >
>
>
> Regards,
> Keith
>
>
>
>
>
--
*Arnon Warshavsky*
*Qwilt | work: +972-72-2221634 | mobile: +972-50-8583058 | arnon at qwilt.com
*
; From: Arnon Warshavsky mailto:arnon at qwilt.com>>
> Date: Thursday, January 21, 2016 at 9:04 AM
> To: "Keith Wiles (Intel)" keith.wiles at intel.com>>
> Cc: Matthew Hall mailto:mhall at mhcomputing.net>>,
> "
> dev at dpdk.org<mailto:dev at dpdk.o
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
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
>
Hi Swamy
A somewhat similar degradation (though not with l2fwd) was experienced by
us as described here
http://dev.dpdk.narkive.com/OL0KiHns/dpdk-dev-missing-prefetch-in-non-vector-rx-function
In our case it surfaced for not using the default configuration and working
in non-vector mode, and it
22 matches
Mail list logo
