Keith,
A bit late, but two very high level questions. Do you have performance
numbers compared to KNI? Did you consider using AF_PACKET PACKET_MMAP which
could potentially reduce the number of syscalls to 1 for RX and TX of a
burst?
Marc
On 12 December 2016 at 15:38, Keith Wiles wrote:
>
> >
> The driver advertises the right speed range supported. The problem is with
> the report about the current link speed configured.
> Maybe, is the right thing to do here to not report the current link speed
> because the driver really does not kno
On 18 February 2016 at 19:14, Mcnamara, John
wrote:
> Hi,
>
> Some minor comments below in order to get a consistent set of release
> notes.
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune
> > Sent: Sunday,
ly.
I would, at most, use a separate git submodule in that location, only
populated at wish.
Having completely separate repository under dpdk.org or simply the PDFs/raw
RST in the website seem better options.
Marc
>
> > * On dpdk.org in PDF format.
> > * Elsewhere.
> >
&
On 29 January 2016 at 11:17, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> > Sent: Friday, January 29, 2016 9:54 AM
> > To: Ananyev, Konstanti
On 29 January 2016 at 14:05, Panu Matilainen wrote:
> On 01/29/2016 02:42 AM, Marc Sune wrote:
>
>> Added rte_eth_speed_to_bm_flag() to DPDK2.2 version map.
>>
>> Signed-off-by: Marc Sune
>> ---
>> lib/librte_ether/rte_ether_version.map | 6
On 29 January 2016 at 17:16, N?lio Laranjeiro
wrote:
> Hi Marc,
>
> On Fri, Jan 29, 2016 at 01:42:05AM +0100, Marc Sune wrote:
> >[...]
> > /**
> > - * Device supported speeds
> > - */
> > -#define ETH_SPEED_CAP_NOT_PHY(0) /*< No phy media >
.html#Configuration-Files)
that to me is more readable and user-friendly than JSON (not to mention
XML).
* As you, Thomas say, and as it has been discussed previously [1]; it would
be good that eal_init was not depending on argv and had a _simple_, and
with reasonable defaults, struct-based init A
mpletely different suggestion into the mix?
>
> Can we make use of the fact that make config creates a directory called
> "build"
> by default. Then running "make" alone in that directory does the expected
> behaviour of a compile of the whole sdk. How about having "make install"
> in the
> build directory behave like a generic "make install" call for other
> packages?
>
> I'm imagining the following sequence of steps to install:
>
> ./configure --machine=[default|native|other]
> # configure is a simple script that just calls "make
> config T=..."
> cd build
>
Why not the inverse, configure in the folder where you build so that you
have all the compilation environment in the target folder (as in
autoconf+automake and as of now in DPDK). You can have easily parallel
builds in different folders.
> make
> make install
>
If you want this workflow, why not directly using autoconf + maybe the
config file there is now (since there are a ton of parameters)? Putting
general configuration parameters into configure.ac and leave the rest to
the config files.
The PREFIX and installation of files is something that automake+autoconf
solves too (probably without libtool for DPDK).
In any case, for install-fhs, I would name it install-all, to make it
consistent with typical autotools build envs, which is what users are used
to.
Marc
> Thoughts?
>
> /Bruce
>
On 9 March 2016 at 09:45, N?lio Laranjeiro
wrote:
> Hi Marc,
>
> A small remark bellow.
>
> On Tue, Mar 01, 2016 at 01:45:50AM +0100, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
&
On 9 March 2016 at 11:09, N?lio Laranjeiro
wrote:
> On Wed, Mar 09, 2016 at 10:29:38AM +0100, N?lio Laranjeiro wrote:
> > On Tue, Mar 08, 2016 at 05:53:05PM +0100, N?lio Laranjeiro wrote:
> > > On Tue, Mar 08, 2016 at 04:00:29PM +0100, Marc Sune wrote:
> > > > 2016-
On 10 March 2016 at 19:23, Thomas Monjalon
wrote:
> 2016-03-03 00:34, Marc Sune:
> > RTE_PMD_DEBUG_TRACE used RTE_FUNC_PTR_OR_ERR_RET was redefined
> > in rte_cryptodev_pmd.h which produced MACRO redefinition warnings
> > when including both rte_cryptodev_pmd.h and rte_e
Vector tx can be enabled on this txq.
> PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are
> satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.
> PMD: i40e_dev_start(): Invalid link_speeds for port 1; autonegotiation
> disabled
>
Just to d
On 24 March 2016 at 07:21, Xu, Qian Q wrote:
> Marc
>
> I didn?t quite get your points, I observed that after applying this
> patchset, all intel nic can?t be started, maybe something wrong happened
> when you check the duplex/autoneg value for different NICs. If we want to
>
st patchsets, but i40 (XL710) and igb (82540EM) were working on
my side for previous versions. Which exact NICs were used to test the
patchset for igb?
Marc
> Regards,
> Helin
>
> > -Original Message-
> > From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com
On 25 March 2016 at 21:41, Marc wrote:
>
> On 25 March 2016 at 16:07, Zhang, Helin wrote:
>
>> Hi Thomas
>>
>> Beilei is investigating that, she will give her findings soon later, and
>> possibly a fix after validating that.
>> Thanks!
>>
>>
On 25 March 2016 at 22:30, Marc wrote:
>
>
> On 25 March 2016 at 21:41, Marc wrote:
>
>>
>> On 25 March 2016 at 16:07, Zhang, Helin wrote:
>>
>>> Hi Thomas
>>>
>>> Beilei is investigating that, she will give her findings soon later,
On 26 March 2016 at 09:08, Thomas Monjalon
wrote:
> Hi Marc,
>
> Thanks for finding time to help.
>
> 2016-03-25 22:30, Marc:
> > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> ETH_LINK_SPEED_FIXED were flipped. Reverting this makes it work:
> >
On 27 March 2016 at 11:53, Thomas Monjalon
wrote:
> 2016-03-26 11:24, Marc:
> > On 26 March 2016 at 09:08, Thomas Monjalon
> > wrote:
> > > 2016-03-25 22:30, Marc:
> > > > From v9 to v10 patchset the values ETH_LINK_SPEED_AUTONEG and
> > > ETH_LINK_S
On 28 March 2016 at 03:54, Lu, Wenzhuo wrote:
> Hi Marc
>
>
>
> *From:* Marc Sune [mailto:marcdevel at gmail.com]
> *Sent:* Saturday, March 26, 2016 9:43 AM
> *To:* dev at dpdk.org; Lu, Wenzhuo
> *Subject:* e1000: randomly loosing link change events triggered by the
>
On 28 March 2016 at 15:42, Thomas Monjalon
wrote:
> Hi Marc,
>
> 2016-03-27 21:39, Marc:
> > On 27 March 2016 at 11:53, Thomas Monjalon
> > wrote:
> > > 2016-03-26 11:24, Marc:
> > > > On 26 March 2016 at 09:08, Thomas Monjalon <
> thomas.monjalo
On 29 March 2016 at 08:18, Xing, Beilei wrote:
>
>
> > -Original Message-
> > From: Marc Sune [mailto:marcdevel at gmail.com]
> > Sent: Saturday, March 26, 2016 9:27 AM
> > To: Thomas Monjalon ; Xu, Qian Q
> > ; Xing, Beilei ;
> dev at dpdk.org
On 29 March 2016 at 03:19, Lu, Wenzhuo wrote:
> Hi Marc,
>
>
>
> *From:* marc.sune at gmail.com [mailto:marc.sune at gmail.com] *On Behalf Of *
> Marc
> *Sent:* Monday, March 28, 2016 7:03 PM
> *To:* Lu, Wenzhuo
> *Cc:* dev at dpdk.org
> *Subject:* Re: e1000: rando
On 29 March 2016 at 15:31, Alejandro Lucero
wrote:
> For nfp.c, speed_capa should be ETH_LINK_SPEED_40G instead of
> ETH_LINK_SPEED_50G.
> By the way, the change in patch 4 sets the right link speed using the new
> constants.
>
> Regards
>
Noted for v14, thanks
Marc
>
kage that just has a list of #defines for the
> old symbols pointing them at the new symbols? That would also allow
> people with old applications to update DPDK without having to modify
> their applications.
>
You would also have to add all typedefs for type names.
Why bothering?
On 1 February 2016 at 01:40, Zhang, Helin wrote:
>
>
> > -Original Message-
> > From: Ananyev, Konstantin
> > Sent: Friday, January 29, 2016 6:18 PM
> > To: Thomas Monjalon
> > Cc: dev at dpdk.org; Marc Sune; Lu, Wenzhuo; Zhang, Helin; Harish Patil
think is enough for future rates in mbps.
Since these constants were there, and before doing something to have to
revert it, can someone else give his/her opinion on this?
If there is consensus, I've no problem on removing it for v8
Thanks
marc
On 11 February 2016 at 16:27, N?lio Laranjeiro
wrote:
> On Tue, Feb 02, 2016 at 11:30:59PM +0100, Marc wrote:
> > On 2 February 2016 at 03:20, Stephen Hemminger <
> stephen at networkplumber.org>
> > wrote:
> >
> > > On Thu, 28 Jan 2016 1
It seems compilation for clang Linux target is broken:
In file included from
/home/marc/dpdk/lib/librte_eal/linuxapp/eal/eal_pci.c:42:
/home/marc/dpdk/x86_64-native-linuxapp-clang/include/rte_memcpy.h:870:2:
error: implicit declaration of function '_mm_alignr_epi8' is inva
On 15 February 2016 at 09:46, N?lio Laranjeiro
wrote:
> On Sun, Feb 14, 2016 at 11:17:38PM +0100, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
> > - it allows to define a set of adver
Rahul, Neilo, Jing D, et al
On 15 February 2016 at 15:43, Rahul Lakkireddy wrote:
> Hi Marc,
>
> On Sunday, February 02/14/16, 2016 at 23:17:37 +0100, Marc Sune wrote:
> > Added speed capabilities to all pmds supporting physical NICs:
> >
> > * e1000
> &
On 16 February 2016 at 12:49, Mcnamara, John
wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc
> > Sent: Sunday, February 14, 2016 10:21 PM
> > To: dev at dpdk.org
> > Subject: [dpdk-dev] x86_64-nati
>
> int
> main(int argc, char **argv)
> {
> RTE_LOG(NOTICE, USER1, "function %s\n", __func__);
> return 0;
> }
>
>
I don't know what you have in mind for the test, but with this file you can
only detect things like using reserved keywords of C++ in DPDK headers and
things like that. It will not detect linking issues (fundamentally missing
extern "C" in function declarations), which happen from time to time,
specially with new headers.
We would need to compile a .cc/.cpp file including all these headers and
link against all the functions on those headers, similarly to what autoconf
does to test libs. I could help on that for 2.4.
Marc
On 16 February 2016 at 16:25, N?lio Laranjeiro
wrote:
> Hi Marc,
>
> On Mon, Feb 15, 2016 at 06:14:42PM +0100, Marc wrote:
> > Rahul, Neilo, Jing D, et al
> >
> > On 15 February 2016 at 15:43, Rahul Lakkireddy <
> rahul.lakkireddy at chelsio.com
> > >
Matej,
On 16 February 2016 at 11:28, Matej Vido wrote:
> D?a 14.02.2016 o 23:17 Marc Sune nap?sal(a):
>
>> This patch redesigns the API to set the link speed/s configure
>> for an ethernet port. Specifically:
>>
>> - it allows to define a set of advertised spe
> When it happens to me I am using a Skylake Core i7-6700K.
>
Broadwell qemu emulated.
Marc
>
> Matthew.
>
now.
Note: this RFC patch is based on v1.7.1, since I was using a 1.7 application.
It will eventually be rebased to 1.8 upon acceptance.
Signed-off-by: Marc Sune
---
config/common_linuxapp |1 +
lib/librte_eal/linuxapp/kni/kni_misc.c |4
2 files changed, 5 inserti
Hi guys,
Any comment, suggestion or objection to this patch? Otherwise I would
send a non-RFC patch
Thanks
Marc
On 05/11/14 01:17, Marc Sune wrote:
> This patch introduces CONFIG_RTE_KNI_PREEMPT flag. When set to 'no', KNI
> kernel thread(s) do not call schedule_timeout_interr
valgrind from sources (3.10.0) and applied
(manually) this patch:
https://bugs.kde.org/attachment.cgi?id=85950&action=edit
(Applied around line 2216)
From this post:
http://valgrind.10908.n7.nabble.com/mpich-unable-to-munmap-hugepages-td49150.html
Happy debugging
Marc
On 07/11/14 01:22, Marc Sune wrote:
> On 16/09/14 13:42, Morten Jagd Christensen wrote:
>> Hi all,
>>
>>
>> I am interested to hear if anyone here have had any luck running
>> Valgrind on
>> DPDK applications?
>>
>>
>> I tried to u
On 07/11/14 02:04, Matthew Hall wrote:
> On Fri, Nov 07, 2014 at 01:22:49AM +0100, Marc Sune wrote:
>> Found some time to have a close look. I also wanted to check a DPDK app
>> against valgrind. It works!
>>
>> I downloaded and compiled valgrind from sources (3.10.
now.
Signed-off-by: Marc Sune
---
config/common_linuxapp |1 +
lib/librte_eal/linuxapp/kni/kni_misc.c |4
2 files changed, 5 insertions(+)
diff --git a/config/common_linuxapp b/config/common_linuxapp
index 57b61c9..24b529d 100644
--- a/config/common_linuxapp
+++ b/co
array or forcing the
applications to add extra DPDK parameters in the executable.
Just my 2 cents ;)
Best
marc
On 01/08/13 18:01, Thomas Monjalon wrote:
> Hello,
>
> 01/08/2013 17:37, Marc Sune :
>> In our case, we are right now simply faking the argv, which is a lit
send the patch here for discussion. At the very end, it was only a
suggestion ;)
Best
marc
On 01/08/13 18:47, Antti Kantee wrote:
> On 1.8.2013 19:13, Marc Sune wrote:
>> Regarding the rte_eal_init(), if the concern is the number of parameters
>> and backwards compatibility, a t
Thanks Stephen for the hack.
Unfortunately, our main already has parameters, and are all
platform(architecture) agnostic, so this would break the assumption that
arguments should be platform agnostic.
But anyway thanks ;)
marc
On 01/08/13 19:06, Stephen Hemminger wrote:
> On Thu, 01 Aug 2
to the
IGB_UIO driver, is it safe to assume that the association phyisical port
<-> port_id will always be the same? Even after reboot, and regardless
of the order that are bound to the IGB_UIO driver (e.g. using
pci_unbind.py)?
Best
marc
are being binded to the DPDK
driver, or when the IGB_UIO driver is insmoded? If it is the former,
then the ids won't be consistent across reboots or binding order, which
is not very desirable (IMHO), and actually is going to cause some
problems in our application.
Best
marc
On 15/08/13 16:57, Ste
of the main() (MAIN) routine. Is
this really necessary? Isn't it enough to clearly state in the
documentation that certain API calls need to be made on the very
beginning of the application?
Best
Marc
---
BISDN GmbH
Marc Su?? Clos
Christburger Stra?e 45, 10405 Berlin, Germany
Berlin Instit
compile it on other Debian-like systems
(Ubuntu), but not on all of them. Of course I can install another OS,
but it is annoying to move from the usual environment, and in principle
it _should_ work.
Any ideas? Am I missing something?
Best regards
marc
--
marc at bertha:~/dpdk
marc
On 04/11/13 15:21, Cyril Cressent wrote:
> Hi Marc,
>
> On Mon, Nov 04, 2013 at 01:58:56PM +0100, Marc Sune wrote:
>> I am unable to compile DPDK 1.5 (and previous versions) on Debian
>> GNU/Linux Wheezy (7) and Squeeze (6).
> I mainly work with a machine runni
Thank you Keith,
But I already tried that before sending the first email. The problem is
that verbose is not showing much more:
marc at bisdn-dev:~/BISDN/dpdk$ make install T=x86_64-default-linuxapp-gcc V=1
make -f /home/marc/BISDN/dpdk/mk/rte.sdkinstall.mk install
== Installing
Dear Thomas, all,
I think it is not this variable. When the folder /lib/modules/$(shell
uname -r)/build does not exist, the Makefile properly warns you (I
manually created it, since it was not existing during the first
compilation attempt).
marc at bisdn-dev:~/BISDN/dpdk$ grep RTE_KERNELDIR
print the right
error, otherwise the output of make is misleading.
As I said thank you and regards
marc
On 05/11/13 16:42, Cyril Cressent wrote:
> Hi Marc,
>
> On Mon, Nov 04, 2013 at 09:53:29PM +0100, Marc Sune wrote:
>> I think it is not this variable. When the folder
>>
Changing the CPU type emulation to some model that supports SSSE3 solved
it (e.g. core2duo) should do the trick. I faced the same problem
sometime ago.
best
marc
On 29/11/13 11:39, Surya Nimmagadda wrote:
> Hi,
>
> I am a beginner with dpdk and trying to follow the instructions i
interested in this particular setup, because we haven't yet
tried our application with some Atom equipment we have here, but we need
to make it run also there.
Any ideas? I am probably missing something really fundamental here.
Thank you and regards
marc
[1]
marc at dpdk:~/dpdk/examples/l2fwd/
guess option a) would be more suitable, is it?
thank you and regards
marc
On 07/04/14 14:55, Richardson, Bruce wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Marc Sune
>> Sent: Monday, April 07, 2014 1:51 PM
>> To:
&g
Maybe useless but, I've also seen this error when trying to configure
e1000's with more than 1 queue.
Sometimes the only way to see such (stupid) errors is to enable the
DEBUG output from the driver:
marc at dpdk:~/dpdk/config$ git diff .
diff --git a/config/defconfig_x86_64-defaul
This usually shows up when you are attempting to compile your DPDK
application without properly defining RTE_SDK and RTE_TARGET (where DPDK
source resides).
Just double check if they are properly defined and exported
marc
On 11/12/14 12:17, sothy shan wrote:
> Hi!
> I am seeking h
into dpdk?
veth are software interfaces, meaning there is no real NIC behind.
That's why you cannot bind them to igb_uio.
You can use KNI interfaces for communicating a DPDK application with the
kernel interfaces and viceversa. There is an overhead on doing so, but
whether this is an app
On 12/12/14 14:57, Sachin Sharma wrote:
> Hi Marc,
> I have limited number of nodes (Linux nodes) in my testbed. So, I wanted to
> use veth interfaces for creating some of dpdk nodes in my nodes. You said
> that I can use KNI interfaces for this purpose. I am very new to KNI
&
to recover them unless a reboot is
performed. Attaching igb_uio -> igb -> gb_uio does not solve it either.
This happens also with 1G copper ports.
Any ideas?
Thanks and regards
marc
p.s. Using 1.5.2 branch right now
-
[0] setup.sh
Option: 10
regards
marc
On 25/02/14 14:00, Ananyev, Konstantin wrote:
> Hi,
>
> Probably try to rebuild with CONFIG_RTE_LIBRTE_IXGBE_DEBUG_*=y and rerun?
> Might be it would give you some insight what is going wrong.
>
> Konstantin
>
> -Original Message-
> From: dev [mailto:
On 20/05/15 10:31, Thomas Monjalon wrote:
> 2015-05-19 12:31, Bruce Richardson:
>> On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrote:
>>> Hi all,
>>>
>>> after a small amount of offline discussion with Marc Sune, here is an
>>> alte
On 20/05/15 12:28, Neil Horman wrote:
> On Wed, May 20, 2015 at 12:05:00PM +0200, Marc Sune wrote:
>>
>> On 20/05/15 10:31, Thomas Monjalon wrote:
>>> 2015-05-19 12:31, Bruce Richardson:
>>>> On Mon, May 11, 2015 at 05:29:39PM +0100, Bruce Richardson wrot
just use one of the kni_fifo_pool (one =>
meaning a a set of 6 FIFOs making a single slot)
* rte_kni_release would return to the pool.
This should solve both issues. We would base the patch on 1.7.2.
Thoughts?
marc
p.s. Lately someone involved with DPDK said KNI would be deprecated in
fut
Danny,
On 23/09/14 18:38, Zhou, Danny wrote:
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Jay Rolette
>> Sent: Tuesday, September 23, 2014 8:39 PM
>> To: Marc Sune
>> Cc: ; dev-team at bisdn.de
>> Subject: Re: [dpd
before any call to rte_kni_alloc() if KNI is used.
Signed-off-by: Marc Sune
---
lib/librte_kni/rte_kni.c | 302 ++
lib/librte_kni/rte_kni.h | 18 +++
2 files changed, 269 insertions(+), 51 deletions(-)
diff --git a/lib/librte_kni/rte_kni.c b/lib
r way to check memory leak
> with dpdk applications?
>
Yes it can be used, just that 3.10 has issues with hugepages. Check this
out:
http://article.gmane.org/gmane.comp.networking.dpdk.devel/8058/match=valgrind+hugepages
Marc
t;> Correctly written code looks for them by name and reuses existing pool
>> if it is big enough.
>>
> FYI, I'm looking into such functionality and also delete/destroy
> mempools (although still no plan on implementation).
>
Also the memzones behind, or will be "lost/leaked" after a mempool
destruction?
Marc
> Sergio
On 16/04/15 11:26, Gonzalez Monroy, Sergio wrote:
> On 16/04/2015 10:22, Marc Sune wrote:
>>
>>
>> On 16/04/15 11:03, Gonzalez Monroy, Sergio wrote:
>>> On 15/04/2015 20:24, Stephen Hemminger wrote:
>>>> On Wed, 15 Apr 2015 20:15:18 +0100
>>>
case RTE_PKT_DEV_ETH:
struct rte_eth_dev* eth_dev = (struct rte_eth_dev*)pkt_dev;
rte_pkt_tx_burst(eth_dev, queue_id, tx_pkts, nb_pkts);
break;
case RTE_PKT_DEV_RING:
//...
}
}
//...
May
On 17/04/15 21:50, Wiles, Keith wrote:
> Hi Marc and Bruce,
Hi Keith, Bruce,
>
> On 4/17/15, 1:49 PM, "Marc Sune" wrote:
>
>>
>> On 17/04/15 17:16, Bruce Richardson wrote:
>>> Hi all,
>>>
>>> to continue this discussion a bit
Bruce,
On 20/04/15 12:43, Bruce Richardson wrote:
> On Mon, Apr 20, 2015 at 08:51:26AM +0200, Marc Sune wrote:
>>
>> On 17/04/15 21:50, Wiles, Keith wrote:
>>> Hi Marc and Bruce,
>> Hi Keith, Bruce,
>>
>>> On 4/17/15, 1:49 PM, "Marc Sune&quo
nd-up not using PRs or issues in github
like the Linux kernel does.
Btw, is this github organization already registered by Intel or some
other company of the community?
https://github.com/dpdk
Marc
>
> Matthew.
On 27/04/15 03:41, Wiles, Keith wrote:
>
> On 4/26/15, 4:56 PM, "Neil Horman" wrote:
>
>> On Sat, Apr 25, 2015 at 04:08:23PM +, Wiles, Keith wrote:
>>>
>>> On 4/25/15, 8:30 AM, "Marc Sune" wrote:
>>>
>>>>
>>&g
On 27/04/15 15:39, Wiles, Keith wrote:
>
> On 4/27/15, 4:52 AM, "Marc Sune" wrote:
>
>>
>> On 27/04/15 03:41, Wiles, Keith wrote:
>>> On 4/26/15, 4:56 PM, "Neil Horman" wrote:
>>>
>>>> On Sat, Apr 25, 2015 at 04:08:23PM +
dpdk:igb_uio driver for the NIC.
When you bind to igb_uio the NIC is "disconnected" from the kernel.
Therefore ifconfig won't work. DPDK applications can configure the PHY
and other parameters via DPDK APIs:
http://dpdk.org/doc/api/
and act as IP endpoints.
Marc
>
> Is the
From: Marc Sune
The current rte_eth_dev_info abstraction does not provide any mechanism to
get the supported speed(s) of an ethdev.
For some drivers (e.g. ixgbe), an educated guess can be done based on the
driver's name (driver_name in rte_eth_dev_info), see:
http://dpdk.org/ml/archive
adds missing speeds to
ETH_SPEED.
The field speed in the struct rte_eth_link is now a bitmap and therefore is
renamed to speeds. This allows to specify a list of speeds to be announced
during autonegociation, as suggested by M. Brorup. Driver do not support yet
this capabilities.
Signed-off-by: Marc
Added speed capabilities to all pmds supporting physical NICs:
* e1000
* ixgbe
* i40
* mlx4
* fm10k
Signed-off-by: Marc Sune
---
drivers/net/e1000/em_ethdev.c| 6 ++
drivers/net/e1000/igb_ethdev.c | 6 ++
drivers/net/fm10k/fm10k_ethdev.c | 3 +++
drivers/net/i40e/i40e_ethdev.c
mit 1/2 message. rebased to v2.1.0. v3 was incorrectly based on
~2.1.0-rc1.
Marc Sune (2):
Added ETH_SPEED_ bitmap in rte_eth_dev_info
Filling speed capability bitmaps in the PMDs
app/test-pmd/cmdline.c| 32 +++
app/test/virtual_
adds missing speeds to
ETH_SPEED.
The field speed in the struct rte_eth_conf is now a bitmap and therefore is
renamed to speeds. This allows to specify a list of speeds to be announced
during autonegociation, as suggested by M. Brorup. Drivers do not support (yet)
this capability.
Signed-off-by: Marc
Added speed capabilities to all pmds supporting physical NICs:
* e1000
* ixgbe
* i40
* mlx4
* fm10k
Signed-off-by: Marc Sune
---
drivers/net/e1000/em_ethdev.c| 6 ++
drivers/net/e1000/igb_ethdev.c | 6 ++
drivers/net/fm10k/fm10k_ethdev.c | 3 +++
drivers/net/i40e/i40e_ethdev.c
2015-10-25 22:59 GMT+01:00 Marc Sune :
> The current rte_eth_dev_info abstraction does not provide any mechanism to
> get the supported speed(s) of an ethdev.
>
> For some drivers (e.g. ixgbe), an educated guess could be done based on the
> driver's name (driver_name in rt
I'll gladly maintain the patch
>>> pool
>>> and send you pull requests.
>> [snip]
>> And that doesn't account for the ~500 patches that come in via pull
>> request from the wireless subtree. Nor does it account for the merge
>> window for net-next being 2 months instead of dpdk's 6 months.
Neil,
I don't want to hinder the discussion but: could you please point me out
where this wireless subtree is?
Maybe I am too blind, but I cannot see it here:
http://dpdk.org/browse/
We are interested in acceleration for wireless NICs.
Marc
[snip]
still having reasonable tests?
>> Also, when there is AVX2 present on the system, what is the compile time
>> like for that code?
>>
>> /Bruce
> Neil, Bruce,
>
> Some data first.
>
> Sandy Bridge without AVX2:
> 1. original w/ 10 constant memcpy: 2'25"
> 2. patch w/ 12 constant memcpy: 2'41"
> 3. patch w/ 63 constant memcpy: 9'41"
>
> Haswell with AVX2:
> 1. original w/ 10 constant memcpy: 1'57"
> 2. patch w/ 12 constant memcpy: 1'56"
> 3. patch w/ 63 constant memcpy: 3'16"
>
> Also, to address Bruce's question, we have to reduce test case to cut down
> compile time. Because we use:
> 1. intrinsics instead of assembly for better flexibility and can utilize more
> compiler optimization
> 2. complex function body for better performance
> 3. inlining
> This increases compile time.
> But I think it'd be okay to do that as long as we can select a fair set of
> test points.
>
> It'd be great if you could give some suggestion, say, 12 points.
>
> Zhihong (John)
>
>
While I agree in the general case these long compilation times is
painful for the users, having a factor of 2-8x in memcpy operations is
quite an improvement, specially in DPDK applications which need to deal
(unfortunately) heavily on them -- e.g. IP fragmentation and reassembly.
Why not having a fast compilation by default, and a tunable config flag
to enable a highly optimized version of rte_memcpy (e.g.
RTE_EAL_OPT_MEMCPY)?
Marc
>
On 21/01/15 14:02, Bruce Richardson wrote:
> On Wed, Jan 21, 2015 at 01:36:41PM +0100, Marc Sune wrote:
>> On 21/01/15 04:44, Wang, Zhihong wrote:
>>>> -Original Message-
>>>> From: Richardson, Bruce
>>>> Sent: Wednesday, January 21, 201
Signed-off-by: Marc Sune
---
lib/librte_ip_frag/rte_ip_frag.h | 8
1 file changed, 8 insertions(+)
diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
index 3989a5a..1083d44 100644
--- a/lib/librte_ip_frag/rte_ip_frag.h
+++ b/lib/librte_ip_frag
Move link_duplex to be part of bitfield. Fixed i40 autoneg flag link
update code. Added rte_eth_speed_to_bm_flag() to .map file. Fixed other
spelling issues. Rebased to current HEAD.
v7: Rebased to current HEAD. Moved documentation to v2.3. Still needs testing
from PMD maintainers.
Marc
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.
Signed-off-by: Marc Sune
---
lib/librte_ether/rte_ethdev.h | 24
1 file changed, 24 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 8710dd7..dbc1599
Added speed capabilities to all pmds supporting physical NICs:
* e1000
* ixgbe
* i40
* mlx4
* fm10k
Signed-off-by: Marc Sune
---
drivers/net/e1000/em_ethdev.c| 6 ++
drivers/net/e1000/igb_ethdev.c | 6 ++
drivers/net/fm10k/fm10k_ethdev.c | 4
drivers/net/i40e
by configuration.
* Added utility function to convert numeric speeds to bitmap
fields.
Signed-off-by: Marc Sune
---
app/test-pmd/cmdline.c | 124 +++--
app/test/virtual_pmd.c | 4 +-
drivers/net/af_packet/rte_eth_af_packet.c
Add new features, ABI changes and resolved issues notice for
the refactored link patch.
Signed-off-by: Marc Sune
---
doc/guides/rel_notes/release_2_3.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst
b/doc/guides/rel_notes
Added rte_eth_speed_to_bm_flag() to DPDK2.2 version map.
Signed-off-by: Marc Sune
---
lib/librte_ether/rte_ether_version.map | 6 ++
1 file changed, 6 insertions(+)
diff --git a/lib/librte_ether/rte_ether_version.map
b/lib/librte_ether/rte_ether_version.map
index d8db24d..2c14ad7 100644
rrent HEAD. Reverted numeric speed to 32 bit in struct
rte_eth_link (no atomic link get > 64bit). Fixed mlx5 driver compilation
and link speeds. Moved documentation to release_16_04.rst and fixed several
issues. Upgrade NIC notes with speed capabilities.
Marc Sune (4):
ethde
Added constants and bitmap to struct rte_eth_dev_info to be used by PMDs.
Signed-off-by: Marc Sune
---
lib/librte_ether/rte_ethdev.h | 24
1 file changed, 24 insertions(+)
diff --git a/lib/librte_ether/rte_ethdev.h b/lib/librte_ether/rte_ethdev.h
index 16da821..83ddbb7
Added speed capabilities to all pmds supporting physical NICs:
* e1000
* ixgbe
* i40
* bnx2x
* cxgbe
* mlx4
* mlx5
* nfp
* fm10k
Signed-off-by: Marc Sune
---
drivers/net/bnx2x/bnx2x_ethdev.c | 1 +
drivers/net/cxgbe/cxgbe_ethdev.c | 1 +
drivers/net/e1000/em_ethdev.c| 6 ++
drivers
or was fixed
by configuration.
* Added utility function to convert numeric speeds to bitmap
fields.
* Added rte_eth_speed_to_bm_flag() to version map.
Signed-off-by: Marc Sune
---
app/test-pipeline/init.c | 2 +-
app/test-pmd/cmdline.c| 124
Add new features, ABI changes and resolved issues notice for
the refactored link patch.
Signed-off-by: Marc Sune
---
doc/guides/nics/overview.rst | 1 +
doc/guides/rel_notes/release_16_04.rst | 27 +++
2 files changed, 28 insertions(+)
diff --git a/doc/guides
RTE_PMD_DEBUG_TRACE used RTE_FUNC_PTR_OR_ERR_RET was redefined
in rte_cryptodev_pmd.h which produced MACRO redefinition warnings
when including both rte_cryptodev_pmd.h and rte_ethdev.h.
This commit moves MACRO definition to rte_cryptodev.c to prevent
this warning.
---
lib/librte_cryptodev/rte_cr
1 - 100 of 239 matches
Mail list logo
