On Tue, Dec 01, 2015 at 02:49:46PM -0500, Matthew Hall wrote:
> On Tue, Dec 01, 2015 at 01:57:39PM +, Bruce Richardson wrote:
> > Hi Matthew,
> >
> > Couple of follow-up questions on this:
> > * do you need the exact same number of bits in both implementations? If we
> > support
> > 21 bits o
On Wed, Dec 02, 2015 at 12:35:16PM +, Bruce Richardson wrote:
> Hi Matthew,
>
> thanks for the info, but I'm not sure I understand it correctly. It seems to
> me that you are mostly referring to the depths/sizes of the tables being used,
> rather than to the "data-size" being stored in each en
y and update BPF filter for each
capture point ID number.
Regards,
Yoshinobu Inoue
From: Bruce Richardson
Subject: Re: [dpdk-dev] 2.3 Roadmap
Date: Tue, 1 Dec 2015 11:58:16 +
> On Tue, Dec 01, 2015 at 08:26:39PM +0900, Yoshinobu Inoue wrote:
>> Hello DPDK list,
>>
>>
On Tue, Dec 01, 2015 at 03:48:54PM +0100, Vincent JARDIN wrote:
> On 01/12/2015 15:27, Panu Matilainen wrote:
> >The problem with that (unless I'm missing something here) is that KNI
> >requires using out-of-tree kernel modules which makes it pretty much a
> >non-option for distros.
>
> It works f
On 12/1/15, 10:54 AM, "dev on behalf of Richardson, Bruce" wrote:
>
>
>> -Original Message-
>> From: Aaron Conole [mailto:aconole at redhat.com]
>> Sent: Tuesday, December 1, 2015 3:31 PM
>> To: Richardson, Bruce
>> Cc: Panu Matilainen ;
On Wed, Dec 02, 2015 at 01:38:07AM +, Wiles, Keith wrote:
> In Pktgen I used tap interface to wireshark and that worked very nicely the
> only problem is it was slow :-(
>
> Having a tap PMD would be nice to be able to remove that code from Pktgen.
All these approaches we discussed so far ha
possible, but if as in normal tcpdump,
an invocation of tcpdump to a KNI interfce could be somehow notified to
the correspondent DPDK port user application, and then the call to
rte_kni_tx_burst() could be automatically enabled/disabled, that's cool.
Thanks,
Yoshinobu Inoue
On 12/01/2015 04:48 PM, Vincent JARDIN wrote:
> On 01/12/2015 15:27, Panu Matilainen wrote:
>> The problem with that (unless I'm missing something here) is that KNI
>> requires using out-of-tree kernel modules which makes it pretty much a
>> non-option for distros.
>
> It works fine with some distr
On 12/01/2015 12:03 PM, Bruce Richardson wrote:
> On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote:
>> On Mon, 30 Nov 2015 22:53:50 +
>> Kyle Larose wrote:
>>
>>> Hi Tim,
>>>
>>> On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim >> intel.com> wrote:
>>>
Tcpdump Support: Su
On Tue, Dec 1, 2015 at 3:58 PM, Panu Matilainen wrote:
> On 12/01/2015 04:48 PM, Vincent JARDIN wrote:
>>
>> On 01/12/2015 15:27, Panu Matilainen wrote:
>>>
>>> The problem with that (unless I'm missing something here) is that KNI
>>> requires using out-of-tree kernel modules which makes it pretty
> -Original Message-
> From: Aaron Conole [mailto:aconole at redhat.com]
> Sent: Tuesday, December 1, 2015 3:31 PM
> To: Richardson, Bruce
> Cc: Panu Matilainen ; dev at dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
>
> Bruce Richardson writes:
> > On T
On 01/12/2015 15:27, Panu Matilainen wrote:
> The problem with that (unless I'm missing something here) is that KNI
> requires using out-of-tree kernel modules which makes it pretty much a
> non-option for distros.
It works fine with some distros. I do not think it should be an argument.
On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote:
> On 12/01/2015 04:48 PM, Vincent JARDIN wrote:
> >On 01/12/2015 15:27, Panu Matilainen wrote:
> >>The problem with that (unless I'm missing something here) is that KNI
> >>requires using out-of-tree kernel modules which makes it pret
On Tue, Dec 01, 2015 at 01:57:39PM +, Bruce Richardson wrote:
> Hi Matthew,
>
> Couple of follow-up questions on this:
> * do you need the exact same number of bits in both implementations? If we
> support
> 21 bits of data in IPv6 and 24 in IPv4 is that an issue compared to supporting
> 21 b
On Tue, Dec 01, 2015 at 10:31:02AM -0500, Aaron Conole wrote:
> The benefit is no dependancy on kernel modules (just TUN/TAP support). I
> don't have a way of signaling sampling, so right now, it's just drinking
> from the firehose.
This is actually quite a good idea. Many years ago I coded up a
On Tue, Dec 01, 2015 at 09:45:56AM -0500, Kyle Larose wrote:
> Earlier Stephen mentioned using the named pipe behaviour of tcpdump.
> Is there an opportunity to take what you have mentioned here and marry
> it to the named pipe output to get the perf you need?
I am wondering about the same thing.
On Tue, Dec 01, 2015 at 08:44:57AM -0500, Matthew Hall wrote:
> On Tue, Dec 01, 2015 at 01:16:47PM +, O'Driscoll, Tim wrote:
> > True. The goal is to merge the best of the various patches that were
> > submitted on this. This could involve changes to IPv6 as well as IPv4.
> >
> >
> > Tim
>
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Matthew Hall
> Sent: Tuesday, December 1, 2015 1:00 PM
> To: O'Driscoll, Tim
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
>
> On Mon, Nov 30, 2015 at 08:50:58PM
On Tue, Dec 01, 2015 at 08:26:39PM +0900, Yoshinobu Inoue wrote:
> Hello DPDK list,
>
> I've been so far just roughly reading messages, as I've been working on my
> company's product based on DPDK1.6 for some time and haven't yet much
> catched up to newer releases,
> but as I implemented packet c
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dave Neary
> Sent: Monday, November 30, 2015 10:19 PM
> To: O'Driscoll, Tim; dev at dpdk.org
> Subject: Re: [dpdk-dev] 2.3 Roadmap
>
> Hi Tim,
>
> Just curious about one item
ttps://01.org/packet-processing/cache-monitoring-technology-memory-bandwidth-monitoring-cache-allocation-technology-code-and-data
Tim
>
> -HK
>
> From: dev on behalf of O'Driscoll, Tim
>
> Sent: Monday, November 30, 2015 9:50:58 P
Bruce Richardson writes:
> On Tue, Dec 01, 2015 at 04:58:08PM +0200, Panu Matilainen wrote:
>> On 12/01/2015 04:48 PM, Vincent JARDIN wrote:
>> >On 01/12/2015 15:27, Panu Matilainen wrote:
>> >>The problem with that (unless I'm missing something here) is that KNI
>> >>requires using out-of-tree ke
On Mon, Nov 30, 2015 at 05:16:55PM -0800, Stephen Hemminger wrote:
> On Mon, 30 Nov 2015 22:53:50 +
> Kyle Larose wrote:
>
> > Hi Tim,
> >
> > On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim > intel.com> wrote:
> >
> > > Tcpdump Support: Support for tcpdump will be added to DPDK. This wil
On Tue, Dec 1, 2015 at 8:42 AM, Matthew Hall wrote:
> I am planning to use this to do the captures so you don't incur the headache
> or performance issues with rte_kni.
>
> I am curious how I might be able to link it up w/ the standard libpcap based
> tools to get an end-to-end solution with min
On Tue, Dec 01, 2015 at 01:16:47PM +, O'Driscoll, Tim wrote:
> True. The goal is to merge the best of the various patches that were
> submitted on this. This could involve changes to IPv6 as well as IPv4.
>
>
> Tim
If it's possible to fix IPv6 as well this would be good for me. Offering a
On Tue, Dec 01, 2015 at 11:58:16AM +, Bruce Richardson wrote:
> Hi,
>
> that is indeed very similar to what we are thinking ourselves. Is there any of
> what you have already done that you could contribute publically to save us
> duplicating some of your effort? [The one big difference, is tha
On Mon, Nov 30, 2015 at 08:50:58PM +, O'Driscoll, Tim wrote:
> Increase Next Hops for LPM (IPv4): The number of next hops for IPv4 LPM is
> currently limited to 256. This will be extended to allow a greater number of
> next hops.
In other threads, we previously proposed doing increased LPM4
Hi Tim,
On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim
wrote:
> Tcpdump Support: Support for tcpdump will be added to DPDK. This will improve
> usability and debugging of DPDK applications.
I'm curious about the proposed tcpdump support. Is there a concrete plan for
this, or is that still
It looks very ambitious :)
Thank you Intel for pushing forward!
2015-11-30 20:50, O'Driscoll, Tim:
> As we're nearing the completion of the 2.2 release, I'd like to start a
> discussion on plans for 2.3. To kick this off, below are the features that
> we're hoping to submit for this release.
>
Hi,
CAT And CDP technologies look very intriguing Could you elaborate a little
on those?
-HK
From: dev on behalf of O'Driscoll, Tim
Sent: Monday, November 30, 2015 9:50:58 PM
To: dev at dpdk.org
Subject: [dpdk-dev] 2.3 Roadmap
As we'
As we're nearing the completion of the 2.2 release, I'd like to start a
discussion on plans for 2.3. To kick this off, below are the features that
we're hoping to submit for this release.
If others are prepared to contribute their plans, then we could build a
complete view of the release which
Hi Tim,
Just curious about one item on the list:
On 11/30/2015 03:50 PM, O'Driscoll, Tim wrote:
> IPsec Sample Application: A sample application will be created which will
> show how DPDK and the new cryptodev API can be used to implement IPsec. Use
> of the cryptodev API will allow either hard
On Mon, 30 Nov 2015 22:53:50 +
Kyle Larose wrote:
> Hi Tim,
>
> On Mon, Nov 30, 2015 at 3:50 PM, O'Driscoll, Tim
> wrote:
>
> > Tcpdump Support: Support for tcpdump will be added to DPDK. This will
> > improve usability and debugging of DPDK applications.
>
> I'm curious about the propo
33 matches
Mail list logo
