Dear Thomas,
I don't have time to follow the DPDK Developers mailing list, but since you
call for feedback, I would like to share my thoughts regarding these design
choices.
Regarding the statistics discussion:
1. The suggested solution assumes that, when statistics is disabled, the cost
of
The suggested solution with only one single flag per library prevents
implementing statistics with varying granularity for different purposes. E.g. a
library could have one set of statistics counters for ordinary SNMP purposes,
and another set of statistics counters for debugging/optimization
Regarding the PHY speed ABI:
1. The Ethernet PHY ABI for speed, duplex, etc. should be common throughout the
entire DPDK. It might be confusing if some structures/functions use a bitmask
to indicate PHY speed/duplex/personality/etc. and other structures/functions
use a combination of an
Bruce,
This doesn't really sound like tcpdump to me; it sounds like port mirroring.
Your suggestion is limited to physical ports only, and cannot be attached
further inside the application, e.g. for mirroring packets related to a
specific VLAN.
Furthermore, it doesn't sound like the filtering
Great idea, Arnon. Let?s look at existing use cases from the real world.
Our company makes network appliances. They are not running GNU/Linux or
similar, so they do not offer a BASH prompt or any other BSD/Linux like command
line interface.
Here?s a simplified description of how the user
Bruce,
Please note that tcpdump is a stupid name for a packet capture application that
supports much more than just TCP.
I had missed the point about ethdev supporting virtual interfaces, so thank you
for pointing that out. That covers my concerns about capturing packets inside
tunnels.
I
Bruce,
Matthew presented a very important point a few hours ago: We don't need tcpdump
support for debugging the application in a lab; we already have plenty of other
tools for debugging what we are developing. We need tcpdump support for
debugging network issues in a production network.
In
Bruce,
Please reconsider your interpretation of the word "debuggability". Debugging is
not only something that R staff does in a lab. Debuggability can also be
interpreted as a network engineer's ability to debug what is happening in a
production network.
Referring to the link you kindly
It is important to consider that a multipath link (bonding etc.) is not a
physical link, but a logical link (built on top of multiple physical links).
Regardless whether it is a Layer2 link aggregate (IEEE 802.1ad, Ethernet
bonding, EtherChannel, DSL pair bonding, etc.) or a Layer3 multipath
Comments inline, marked MB>.
Med venlig hilsen / kind regards
- Morten Br?rup
Marc Sune on 14. september 2015 23:34 wrote:
2015-09-14 12:52 GMT+02:00 Morten Br?rup :
> It is important to consider that a multipath link (bonding etc.) is not a
> physical link, but a logical link (built on top
Very valid question, Thomas. It's always a good idea to take a step back and
look at the bigger picture!
Unfortunately, I can mention at least one company that has network appliances
in production using such low speeds, and even half duplex: ours (SmartShare
Systems). Basing our appliances on
Marc, here's a couple of details that I missed in my email below:
Correction: 1000BASE-T and 1000BASE-X also have half duplex, so full/half
duplex is relevant for 10, 100 and 1000 Mbit/s speeds.
The bitmap in 3/ (result) probably also needs a bit ("NO_MEDIA" or whatever) to
indicate if a media
Nelio, Marc,
I think Marc is on the right track here: You should design the API based on
requirements and usefulness, not based on what is already implemented in some
drivers. And as Marc pointed out, this is control plane stuff, so performance
should not be an issue.
Let me throw in
Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com] on 15. september 2015
12:05:
> A given link cannot be simultaneously at 10 Gbps and 1 Gbps right? Using a
> bit-field for the current link speed is confusing at best. Output values do
> not need to be included in the unified API, they are
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Dai, Wei
> Sent: Wednesday, November 2, 2016 9:29 AM
> To: Thomas Monjalon; Mcnamara, John; Ananyev, Konstantin; Wu, Jingjing;
> Zhang, Helin; Dai, Wei; Curran, Greg
> Cc: dev at dpdk.org
> Subject: Re:
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton
> Sent: Thursday, November 3, 2016 3:01 AM
>
> On 02/11/2016 17:07, Mcnamara, John wrote:
> [..]
> > Perhaps we could an API that returns a struct, or otherwise, that
> > indicated what stats are
First of all: Thanks for a great DPDK Userspace 2016!
Continuing the Userspace discussion about Olivier Matz?s proposed mbuf
changes...
1.
Stephen Hemminger had a noteworthy general comment about keeping metadata for
the NIC in the appropriate section of the mbuf: Metadata generated by
Comments inline.
Med venlig hilsen / kind regards
- Morten Br?rup
> -Original Message-
> From: Adrien Mazarguil [mailto:adrien.mazarguil at 6wind.com]
> Sent: Tuesday, October 25, 2016 11:39 AM
> To: Bruce Richardson
> Cc: Wiles, Keith; Morten Br?rup; dev at dpdk.org; Olivier Matz; Oleg
Comments inline (at the end).
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev,
> Konstantin
> Sent: Tuesday, October 25, 2016 12:03 PM
> To: Richardson, Bruce; Morten Br?rup
> Cc: Wiles, Keith; dev at dpdk.org; Olivier Matz
> Subject: Re: [dpdk-dev]
Comments inline.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Tuesday, October 25, 2016 1:14 PM
> To: Adrien Mazarguil
> Cc: Morten Br?rup; Wiles, Keith; dev at dpdk.org; Olivier Matz; Oleg
> Kuporosov
> Subject: Re: [dpdk-dev]
Comments at the end.
Med venlig hilsen / kind regards
- Morten Br?rup
> -Original Message-
> From: Bruce Richardson [mailto:bruce.richardson at intel.com]
> Sent: Tuesday, October 25, 2016 2:20 PM
> To: Morten Br?rup
> Cc: Adrien Mazarguil; Wiles, Keith; dev at dpdk.org; Olivier Matz;
Comments inline.
Med venlig hilsen / kind regards
- Morten Br?rup
> -Original Message-
> From: Shreyansh Jain [mailto:shreyansh.jain at nxp.com]
> Sent: Tuesday, October 25, 2016 1:54 PM
> To: Bruce Richardson
> Cc: Wiles, Keith; Morten Br?rup; dev at dpdk.org; Olivier Matz
> Subject:
I support that!
Med venlig hilsen / kind regards
- Morten Br?rup
> -Original Message-
> From: Olivier Matz [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, October 25, 2016 3:14 PM
> To: Morten Br?rup; dev at dpdk.org
> Subject: Re: mbuf changes
>
> Hi,
>
> On 10/24/2016 05:49 PM,
Lots of good arguments from Konstantin below!
Thomas also wrote something worth repeating:
"The mbuf space must be kept jealously like a DPDK treasure :)"
Maybe we should take a step away from the keyboard and consider the decision
process and guidance criteria for mbuf members.
Here is an
> From: Alejandro Lucero [mailto:alejandro.lucero at netronome.com]
> On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson intel.com> wrote:
> > On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
> > > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
> > > > On Mon, Oct 24,
Comments below.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Remy Horton
> Sent: Friday, October 28, 2016 3:05 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [RFC PATCH v2 2/3] lib: add bitrate statistics
> library
>
> This patch adds a library that
Comments at the end.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Pattan, Reshma
> Sent: Friday, October 28, 2016 3:35 PM
> To: Olivier Matz
> Cc: dev at dpdk.org; Morten Br?rup
> Subject: Re: [dpdk-dev] mbuf changes
>
> Hi Olivier,
>
> > -Original
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Richardson, Bruce
> Sent: Friday, October 28, 2016 7:01 PM
> To: Adrien Mazarguil; Morten Br?rup
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] mbuf changes
>
> > -Original Message-
> > From: dev
About the mbuf timestamp (regardless of size etc.) accuracy:
We should also consider the clock source. If the NIC HW is the clock source,
there will be a fixed offset from the CPU's clock, but there will also be
varying drift (they have separate XTALs). And if there are multiple NICs, there
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier Matz
> Sent: Tuesday, October 25, 2016 2:49 PM
>
> We should keep in mind that today we have the seqn field but it is not
> used by any PMD. In case it is implemented, would it be a per-queue
> sequence
30 matches
Mail list logo
