Hi.
I just pulled new patches from the master branch, and found that it doesn't
work with C++.
in lib/librte_eal/common/include/generic/rte_cycles.h
missing opening extern "C" in
commit fa4001c30ee9d9ecfb3ca5d93d68ef0394e9950a
here is the fix.
-
* Simple Time Reference Functions (Cycles
Since commit d798a94 ("mac vlan filter"),
ICC reports this error:
lib/librte_pmd_i40e/i40e_ethdev.c(1763): error #188:
enumerated type mixed with another type
Indeed, RTE_ETH_FILTER_NONE comes from enum rte_filter_type but
enum rte_filter_op is expected.
Signed-off-by: Thomas Monj
> Since commit d798a94 ("mac vlan filter"),
> ICC reports this error:
> lib/librte_pmd_i40e/i40e_ethdev.c(1763): error #188:
> enumerated type mixed with another type
>
> Indeed, RTE_ETH_FILTER_NONE comes from enum rte_filter_type but
> enum rte_filter_op is expected.
>
> Signed-off-b
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 use this some time ago, but Valgrind does not seem to work
> together with hugepages ? or
>
> I am doing som
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 use this some time ago, but Valgrind does not seem to work
>> togeth
>> As to HW TX checksum offload, do you have special requirement for
>> implementing TSO?
> Yes. TSO implies TX TCP and IP checksum offload.
Is this a general requirement or something specific to ixgbe/i40e? FWIW,
vmxnet3 device does not support tx IP checksum offload but doe support TSO. In
I did not included the generic header directly.
I thought that this nested "extern C" is intended,
however, according to your reply, this might be removed at all.
There is a remaining
"""
#ifdef _cplusplus
}
#endif
"""
at the end of "generic/rte_cycles.h".
I think this should be removed. This caus
Hi Xie,
Do you have a plan to fix coding style of 'librte_vhost/vhost-net-cdev.h'?
Especially, PRINT_PACKET macro.
Thanks,
Tetsuya
(2014/11/06 13:46), Huawei Xie wrote:
> This patchset fixes serious coding style issues in vhost library.
>
> Huawei Xie (2):
> fix alignment, lengthy lines, misor
Tetsuya:
Will do careful review.
You send all the patches including vhost-user implementation, seems I don't
have to send mine, :).
When do you plan to send formal patch?
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Thursday, Novem
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.0) and applied
>> (manually) this
Tested-by: Erlu Chen
- Tested Commit: 23fcffe8ffaccf8a2901050e7daa4979597141ed
- OS: Linux fc20 3.11.10-301.fc20.x86_64
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- GCC: gcc version 4.8.3 20140624
- NIC: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
Intel Corporat
hi,
NETDP news :
UDP protocol and part of socket layer are porting into NETDP.
Another application could establish UDP socket via NETDP, and could communicate
with remote application on other PC.
Packets ZERO copy between application and NETDP.
No lock in UDP stack and socket layer.
Running on m
Hi Xie,
(2014/11/07 12:33), Xie, Huawei wrote:
> Tetsuya:
> Will do careful review.
> You send all the patches including vhost-user implementation, seems I don't
> have to send mine, :).
> When do you plan to send formal patch?
>
Sorry, I just thought you also wanted to check vhost-user implemen
https://github.com/fastos/fastsocketIt's?a highly scalable socket and its
underlying networking implementation of Linux kernel.?It isn't base DPDK, but
the goal is closed. it has been deployed in the production environment of SINA
Weibo (The largest Chinese Twitter)? .?In a chinese review,
h
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, November 06, 2014 10:10 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: nakajima.yoshihiro at lab.ntt.co.jp; masutani.hitoshi at lab.ntt.co.jp;
> Thomas
> Monjalon (thomas.monjalon at 6wind.com)
> Sub
Tested-by: Erlu Chen
- Tested Commit: b82da759779ee56d74ce36dc5a1020c60be9ca24
- OS: Linux fc20 3.11.10-301.fc20.x86_64
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- GCC: gcc version 4.8.3 20140624
- NIC: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [8086:1572]
Intel Corporat
Hello,
On Fri, Nov 7, 2014 at 2:26 AM, Keunhong Lee wrote:
> I did not included the generic header directly.
> I thought that this nested "extern C" is intended,
> however, according to your reply, this might be removed at all.
>
> There is a remaining
> """
> #ifdef _cplusplus
> }
> #endif
> ""
Hi Xie,
(2014/11/07 14:24), Xie, Huawei wrote:
> What about vhost-user implementation?
It seems I misunderstand your comment. I will send all vhost-user files.
> We try to fix all of them if possible, but it is ok to leave some warnings,
> for example,
> lengthy lines.
Thanks, I will.
Tetsuya
Following the big headers rework, all C++ stuff has moved to arch-specific
headers. The generic headers should not contain this so that this is done only
once.
There was a remaining #ifdef __cplusplus in "eal: split CPU cycle operation to
architecture specific" (fa4001c30ee9).
Reported-by: Keunhon
A multiple process DPDK application must mmap hugepages and pci resource into
same virtual addresses. By default the virtual addresses chosen by the primary
process automatically when calling the mmap. But sometime the virtual addresses
chosen by the primary process isn't usable at secondary pro
On Fri, Nov 07, 2014 at 04:01:24PM +0800, lxu wrote:
> A multiple process DPDK application must mmap hugepages and pci resource into
> same virtual addresses. By default the virtual addresses chosen by the
> primary process automatically when calling the mmap. But sometime the virtual
> addresse
On Thu, Nov 06, 2014 at 09:52:25PM +0200, jigsaw wrote:
> Hi Bruce,
>
> Actually IMHO it is good to leave the freedom to user to decide how to
> interpret the tag value, i.e. remove the OR 1 bit.
> If the tag value is zero, then we assume the programmer know what he is
> doing. Of course this shal
The commit message looks fine to me, but VFIO code needs to be adjusted the
same way.
Also, now that I think of it, you can't simply assume that whatever last memseg
you have has the latest virtual address. When IVSHMEM is initialized, it too
reserves some space in the virtual memory, which can
On Thu, Nov 06, 2014 at 04:28:18PM -0500, Kamraan Nasim wrote:
> Greetings,
>
> I have been hitting this issue fairly consistently for the ixgbe driver
>
> MEMPOOL: obj=0x7ffeed1f5d00, mempool=0x7ffeecb69bc0, cookie=badbadbadadd2e55
> PANIC in __mempool_check_cookies():
> MEMPOOL: bad header cook
How to find the?maximum end virtual address ??I'm not the DPDK expert, but I
will try to do my best.
If the segments isn't overlap, "if(seg->addr > last->addr)?last = seg;"
already find the segment with?maximum end virtual address.
Ah, yes, sorry about that, haven?t quite woke up yet ? You?re right. So it?s
removing the dependency on --base-virtaddr, moving the function to eal_pci.c
and adding similar VFIO code that?s left then.
Thanks,
Anatoly
From: XU Liang [mailto:liang...@cinfotech.cn]
Sent: Friday, November 7, 2014
This patch introduces CONFIG_RTE_KNI_PREEMPT flag. When set to 'no', KNI
kernel thread(s) do not call schedule_timeout_interruptible(), which improves
overall KNI performance at the expense of CPU cycles (polling).
Default values is 'yes', maintaining the same behaviour as of now.
Signed-off-by:
From: Pawel Wodkowski
v2 changes:
New version handles race issues with setting/cancelin callbacks,
fixes promiscus mode setting in mode 4 and some other minor errors in mode 4
implementation.
v3 changes:
This is a rework of previous patchset. Basic functionality i the same but
contain following
From: Pawel Wodkowski
Signed-off-by: Pawel Wodkowski
---
app/test-pmd/cmdline.c |2 ++
app/test-pmd/csumonly.c |9
app/test-pmd/icmpecho.c | 17 ++-
app/test-pmd/iofwd.c|9
app/test-pmd/macfwd-retry.c |9
app/test-pm
From: Pawel Wodkowski
Signed-off-by: Pawel Wodkowski
---
lib/librte_ether/rte_ether.h |1 +
lib/librte_pmd_bond/Makefile |2 +
lib/librte_pmd_bond/rte_eth_bond.h|5 +
lib/librte_pmd_bond/rte_eth_bond_8023ad.c | 1185
2014-11-08 01:35, Sujith Sankar:
> ENIC PMD is the poll-mode driver for the Cisco Systems Inc. VIC to be
> used with DPDK suite.
Great to see you on board!
Thank you to contribute a new driver.
--
Thomas
Hi,
2014-11-07 11:04, Michal Jastrzebski:
> From: Pawel Wodkowski
>
>
> Signed-off-by: Pawel Wodkowski
Michal, if you worked on this patch you should add your signed-off-by.
I think it would be a good idea to briefly describe the bonding mode 4
in the commit log.
Thanks
--
Thomas
> Following the big headers rework, all C++ stuff has moved to arch-specific
> headers. The generic headers should not contain this so that this is done only
> once.
> There was a remaining #ifdef __cplusplus in "eal: split CPU cycle operation to
> architecture specific" (fa4001c30ee9).
>
> Report
On Sat, Nov 08, 2014 at 01:35:42AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> lib/librte_pmd_enic/LICENSE | 23 +++
> 1 file changed, 23 insertions(+)
> create mode 100644 lib/librte_pmd_enic/LICENSE
>
> diff --git a/lib/librte_pmd_enic/LICENSE b/lib/
On Sat, Nov 08, 2014 at 01:35:41AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> app/test-pmd/testpmd.c | 1 +
> config/common_linuxapp | 6 ++
> lib/Makefile | 1 +
> lib/librte
On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote:
> Signed-off-by: Sujith Sankar
> ---
> lib/librte_pmd_enic/Makefile | 66
>
> 1 file changed, 66 insertions(+)
> create mode 100644 lib/librte_pmd_enic/Makefile
>
> diff --git a/lib/libr
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, November 07, 2014 12:15 PM
> To: Jastrzebski, MichalX K; Wodkowski, PawelX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v3 1/2] bond: add mode 4 support
>
> Hi,
>
> 2014-11-07 11:0
Many informations in the release notes are not well adapted to an integration.
Please could you rework it?
I'd like to create a doc directory for drivers (doc/drivers) as doc/guides.
So this doc should be in rst format in order to be processed by sphinx and
published on the web site (like guides).
Signed-off-by: Declan Doherty
---
lib/librte_pmd_bond/rte_eth_bond_pmd.c | 65 +++---
1 file changed, 36 insertions(+), 29 deletions(-)
diff --git a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
index de0cd56..f2fe930 100644
--- a/l
Adding support for lsc interrupt from bonded device to link
bonding library with supporting unit tests in the test application.
Signed-off-by: Declan Doherty
---
app/test/test_link_bonding.c | 213 +++--
lib/librte_pmd_bond/rte_eth_bond_api.c | 4 +
lib/li
v6:
- Re-based to dpdk.org addressing associated issues for MBUF_REFCNT
- Added details to testpmd user guide for new command to set link status
polling interval.
v5:
- Fix uninitialized variable in broadcast_tx_burst function which caused a
build error in 32-bit build
- Address unit test issue
Signed-off-by: Declan Doherty
---
lib/librte_pmd_bond/rte_eth_bond_pmd.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/librte_pmd_bond/rte_eth_bond_pmd.c
b/lib/librte_pmd_bond/rte_eth_bond_pmd.c
index f2fe930..6e770af 100644
--- a/lib/librte_pmd_bond/rte_eth
Signed-off-by: Declan Doherty
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/testpmd.c | 3 ++-
app/test-pmd/testpmd.h | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/app/test-pmd/cmdline.c b/app/test-pmd/cmdline.c
index 4c3fc76..be12c13 100644
--- a/app/test-pmd/cmdline.
Signed-off-by: Declan Doherty
---
app/test/packet_burst_generator.c | 25 -
app/test/packet_burst_generator.h | 6 +-
app/test/test_link_bonding.c | 14 +-
3 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/app/test/packet_burst_generat
Signed-off-by: Declan Doherty
---
app/test/test_link_bonding.c | 393 -
app/test/virtual_pmd.c | 79 +--
app/test/virtual_pmd.h | 7 +
lib/librte_pmd_bond/rte_eth_bond_pmd.c | 83 +--
4 files changed, 524 inser
Signed-off-by: Declan Doherty
---
app/test/test_link_bonding.c | 2574 +-
1 file changed, 1036 insertions(+), 1538 deletions(-)
diff --git a/app/test/test_link_bonding.c b/app/test/test_link_bonding.c
index 4aa57a7..aa6a52f 100644
--- a/app/test/test_link
Signed-off-by: Declan Doherty
---
app/test-pmd/cmdline.c | 63 +
app/test/test.h | 7 +-
app/test/test_link_bonding.c| 265 ---
app/test/virtual_pmd.c | 17 +-
app/test/virtual_pmd.h
Hi Bruce,
2014-09-24 09:03, Richardson, Bruce:
> From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > On Tue, Sep 23, 2014 at 12:08:15PM +0100, Bruce Richardson wrote:
> > > --- a/app/test-pmd/testpmd.c
> > > +++ b/app/test-pmd/testpmd.c
> > > @@ -225,7 +225,9 @@ struct rte_eth_thresh tx_thresh
Hi,
I'm currently using the --vdev option to create virtual devices, mainly
for testing. I noticed that these virtual devices are not being
white-listed any more. That was the original behaviour when the option
was called --use-device. Instead of that the virtual device is being
added to the d
Hi Bruce,
>> If a tag value of zero is ever passed in, then it will start matching
against cores which are not doing any processing.
Yes, this is true according to current bookkeeping of inflight tags.
But if the slot in in_flight_tags is not a uint32_t but a struct which has
a filed as indicat
2014-07-03 15:54, Helin Zhang:
> As i40e introduced recently in DPDK, the warnings should include
> i40e when no supported NIC port found during initialization at
> least in below example applications.
> * app/testpmd
> * exception_path
> * kni
>
> Signed-off-by: Helin Zhang
I think it's better
These references to drivers break the layering isolation between
application and drivers.
Signed-off-by: Thomas Monjalon
---
app/test-pmd/testpmd.c | 7 +--
examples/exception_path/main.c | 4 +---
examples/kni/main.c| 4 +---
3 files changed, 3 insertions(+), 12 deletion
Hi Nicolas,
2014-11-07 12:36, Nicolas Pernas Maradei:
> I'm currently using the --vdev option to create virtual devices, mainly
> for testing. I noticed that these virtual devices are not being
> white-listed any more. That was the original behaviour when the option
> was called --use-device. I
Hi,
I get this error compiling the latest download from dpdk.org on a sandybridge.
Am I missing any steps in between that makes the header visible?
The box is a sandybridge and I executed make config T=x86_64-native-linuxapp-gcc
which succeed with no errors.
Then on a make,
$ make
== Build scri
>
> Hi,
>
> 2014-11-07 11:04, Michal Jastrzebski:
> > From: Pawel Wodkowski
> >
> >
> > Signed-off-by: Pawel Wodkowski
>
> Michal, if you worked on this patch you should add your signed-off-by.
>
I temporary lost ability to use git send-email command so I asked Michal
to send those patches
On 07/11/14 12:55, Thomas Monjalon wrote:
> It's by design. If you add a vdev, you want to use it and there is no
> reason to whitelist it, and especially no reason to blacklist a device
> you created for your usage.
>
> Do you agree?
Hi Thomas,
Generally speaking you probably won't want to white
On Fri, Nov 07, 2014 at 01:13:37PM +, Nicolas Pernas Maradei wrote:
> On 07/11/14 12:55, Thomas Monjalon wrote:
> >It's by design. If you add a vdev, you want to use it and there is no
> >reason to whitelist it, and especially no reason to blacklist a device
> >you created for your usage.
> >
>
On 07/11/14 13:26, Neil Horman wrote:
> Then you create the pcap device with --vdev, and simply don't load the pmds
> for
> any of your physical devices (or just don't use pci-whitelist at all if you're
> doing a static build). If you do that, then the corresponding niantic driver
> won't initia
On Fri, Nov 07, 2014 at 01:30:53PM +0100, Thomas Monjalon wrote:
> Hi Bruce,
>
> 2014-09-24 09:03, Richardson, Bruce:
> > From: Neil Horman [mailto:nhorman at tuxdriver.com]
> > > On Tue, Sep 23, 2014 at 12:08:15PM +0100, Bruce Richardson wrote:
> > > > --- a/app/test-pmd/testpmd.c
> > > > +++ b/a
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Michal Jastrzebski
> Sent: Friday, November 07, 2014 11:04 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v3 0/2] bond: mode 4 support
>
> From: Pawel Wodkowski
>
> v2 changes:
> New version handles r
On Fri, Nov 07, 2014 at 02:38:13PM +0200, jigsaw wrote:
> Hi Bruce,
>
> >> If a tag value of zero is ever passed in, then it will start matching
> against cores which are not doing any processing.
>
> Yes, this is true according to current bookkeeping of inflight tags.
>
> But if the slot in in
2014-11-07 13:39, Nicolas Pernas Maradei:
> On 07/11/14 13:26, Neil Horman wrote:
> > Then you create the pcap device with --vdev, and simply don't load the pmds
> > for
> > any of your physical devices (or just don't use pci-whitelist at all if
> > you're
> > doing a static build). If you do th
On Fri, Nov 07, 2014 at 01:39:52PM +, Nicolas Pernas Maradei wrote:
>
> On 07/11/14 13:26, Neil Horman wrote:
> >Then you create the pcap device with --vdev, and simply don't load the pmds
> >for
> >any of your physical devices (or just don't use pci-whitelist at all if
> >you're
> >doing a
2014-11-06 13:55, Bruce Richardson:
> From: "Bruce Richardson"
>
> Add in some additional comments around more complex areas of the code
> so as to make the code easier to read and understand.
>
> Signed-off-by: Bruce Richardson
Applied
Qinglai, if you change the design, you'll now have some
On 07/11/14 14:02, Neil Horman wrote:
> Ah, you want the -w option then, it still appears in the short options list in
> my tree. That sets up the option parsing for all pci devices to require
> whitelisting to be initalized. virtual devices are exempt from this process
> because declaring them wi
Hi Bruce,
Pls have a quick look at the diff to see if this is exactly what you mean
about the bitmask.
I just wrote it without even compiling, just to express the idea. So it may
leave some places unpatched.
If this is agreed, I will make a decent test to verify it before sending
the patch for RFC
Hi Thomas,
Thanks for the reminder. I didn't notice the change in comments yet.
thx &
rgds,
-qinglai
On Fri, Nov 7, 2014 at 4:08 PM, Thomas Monjalon
wrote:
> 2014-11-06 13:55, Bruce Richardson:
> > From: "Bruce Richardson"
> >
> > Add in some additional comments around more complex areas of t
Because vfio and uio can be used at the same time, we need save the value of
requested_addr at?pci_vfio_map_resource() and?pci_uio_map_resource().Your guys
like add a?global?variable "void * pci_requested_addr" or a "void**
requested_addr" parameter at?pci_vfio_map_resource() and?pci_uio_map_res
On Fri, Nov 07, 2014 at 04:31:18PM +0200, jigsaw wrote:
> Hi Bruce,
>
> Pls have a quick look at the diff to see if this is exactly what you mean
> about the bitmask.
> I just wrote it without even compiling, just to express the idea. So it may
> leave some places unpatched.
> If this is agreed, I
Yeah that's better. As below, right?
@@ -290,6 +294,7 @@ rte_distributor_process(struct rte_distributor *d,
match |= (!(d->in_flight_tags[i] ^ new_tag)
<< i);
+ match &= d->in_flight_bitmask;
Since commit 08b563ffb19 ("mbuf: replace data pointer by an offset"),
KNI vhost compilation (CONFIG_RTE_KNI_VHOST=y) was broken.
rte_pktmbuf_mtod() is not used in the kernel context but is replaced
by a simple addition of the base address and the offset.
Signed-off-by: Thomas Monjalon
---
lib/l
2014-11-07 14:28, Nicolas Pernas Maradei:
> Thanks for your reply. The -w option is the same as --pci-whitelist
> mentioned in my first email. Declaring a virtual device with --vdev
> means that I want to use it but there doesn't seem to be a way to say
> that I want to use only that device. Cle
A multiple process DPDK application must mmap hugepages and pci resources into
same virtual addresses. By default the virtual addresses chosen by the primary
process automatically when calling the mmap. But sometime the chosen virtual
addresses isn't usable at secondary process. Such as the seco
Hi Bruce,
I was not doing anything specific for binding the NICs to IGB_UIO (like
invoking "dpdk_nic_bind.py" script explicitly) when using my application
with DPDK 1.6.0. The e1000 devices assigned via virt-manager to the VM were
automatically getting picked up and initialized by IGB_UIO within e
On 07/11/14 14:57, Thomas Monjalon wrote:
> OK, now I better understand your need.
> I think that your use case was simply forgotten when designing the
> new behaviour.
> Could you prepare a patch for this need?
> Or maybe you could workaround with a script based on lspci to blacklist all
> network
> Since Declan sent a v6 for link bonding changes, maybe it is a good idea
> to send another version, as v5 will not be merged.
>
> Pablo
Hi Pablo
I compared v6 patches vs patches produced by git rebase v5 patches
on top which I used to produce mode 4 v3 patches and I think they are
compatible.
On Fri, Nov 07, 2014 at 04:52:46PM +0200, jigsaw wrote:
> Yeah that's better. As below, right?
Yep.
>
> @@ -290,6 +294,7 @@ rte_distributor_process(struct rte_distributor *d,
> match |= (!(d->in_flight_tags[i] ^ new_tag)
> <
Hi Thomas,
On 11/07/2014 03:51 PM, Thomas Monjalon wrote:
> Since commit 08b563ffb19 ("mbuf: replace data pointer by an offset"),
> KNI vhost compilation (CONFIG_RTE_KNI_VHOST=y) was broken.
>
> rte_pktmbuf_mtod() is not used in the kernel context but is replaced
> by a simple addition of the bas
Hi Liang,
I see you are learning how to send a patch. It's a good thing.
I don't know if the idea of your patch will be accepted but here are more tips
about formatting:
- You should use checkpatch.pl from kernel.org and fix the most important issues
- The commit log should be wrapped to avoid lon
Um, not sure I agree with this implementation. I think a cleaner way would be
to put the requested_addr in pci_uio_map_resource and pci_vfio_map_resource (or
rather, put it in include/eal_pci_init.h, like extern void *requested_addr) but
make actual use of it in pci_uio/vfio_map_resource only (a
Pawe?
> -Original Message-
> From: Wodkowski, PawelX
> Sent: Friday, November 07, 2014 16:05
> To: De Lara Guarch, Pablo; Jastrzebski, MichalX K
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v3 0/2] bond: mode 4 support
>
> > Since Declan sent a v6 for link bonding changes, ma
OK thanks Bruce. I will get the patch done in coming week. -qinglai
On Fri, Nov 7, 2014 at 5:04 PM, Bruce Richardson wrote:
> On Fri, Nov 07, 2014 at 04:52:46PM +0200, jigsaw wrote:
> > Yeah that's better. As below, right?
>
> Yep.
>
> >
> > @@ -290,6 +294,7 @@ rte_distributor_process(struct rte
I got it. Just some guys don't like global variable. I'm not sure what is DPDK
code
style.--From:Burakov,
Anatoly Time:2014 Nov 7 (Fri) 23 : 15To:??
, dev at dpdk.org Cc:thomas.monjalon
at 6wind.com , De Lara Guarch, Pablo
Subjec
On Fri, Nov 07, 2014 at 08:31:34PM +0530, Manoj Viswanath wrote:
> Hi Bruce,
>
> I was not doing anything specific for binding the NICs to IGB_UIO (like
> invoking "dpdk_nic_bind.py" script explicitly) when using my application
> with DPDK 1.6.0. The e1000 devices assigned via virt-manager to the
Hi Neil,
Thanks for the comments. I shall work on the modifications that you have
suggested and get back with V2.
Regards,
-Sujith
On 07/11/14 5:04 pm, "Neil Horman" wrote:
>On Sat, Nov 08, 2014 at 01:35:43AM +0530, Sujith Sankar wrote:
>> Signed-off-by: Sujith Sankar
>> ---
>> lib/librte_p
Sujith,
It seems that this PMD is based on DPDK 1.7.
Could you rebase it on HEAD?
Thank you
--
Thomas
2014-11-08 01:35, Sujith Sankar:
> lib/librte_pmd_enic/src/cq_desc.h | 122
> lib/librte_pmd_enic/src/cq_enet_desc.h | 257
> lib/librte_pmd_enic/src/rq_enet_desc.h | 72 +++
> lib/librte_pmd_enic/src/vnic_cq.c | 113
> lib/librte_pmd_enic/src/vnic_cq.h
Hi Thomas,
Thank you for the comments.
I?ll work on moving the release notes to rst and add performance numbers
with testpmd. Once I fix these and Neil?s comments, I shall get back with
version 2.
Thanks,
-Sujith
On 07/11/14 5:50 pm, "Thomas Monjalon" wrote:
>Many informations in the release
Thomas,
Let me work on that too.
Thanks,
-Sujith
On 07/11/14 9:17 pm, "Thomas Monjalon" wrote:
>Sujith,
>
>It seems that this PMD is based on DPDK 1.7.
>Could you rebase it on HEAD?
>
>Thank you
>--
>Thomas
Hi!
Do you know any definition of system level L3 performance?
I was reading slides of IDF14. They are saying they achieved 320 Gbps of
systel level L3 performance using DPDK 1.7.O in Intel Xeon E5_2699 V3
But they used two 10G ports. I wondering the relationship.
Thank for your explanation.
B
Thomas,
I'm seeing an issue with ixgbevf speed/duplex reporting that appears to have
been introduced with
commit 8ef32003772a14c61c70b540e41c259c482c2fb6
(http://www.dpdk.org/browse/dpdk/commit/lib/librte_pmd_ixgbe/ixgbe/ixgbe_vf.c?id=8ef32003772a14c61c70b540e41c259c482c2fb6)
The issue I'm seei
> -Original Message-
> From: Doherty, Declan
> Sent: Friday, November 07, 2014 12:23 PM
> To: dev at dpdk.org
> Cc: De Lara Guarch, Pablo; thomas.monjalon at 6wind.com; Doherty, Declan
> Subject: [PATCH v6 0/8] link bonding
>
> v6:
> - Re-based to dpdk.org addressing associated issues fo
Hi,
Thank you for reporting and explaining the issue.
You have already sent a bug report and a patch for this issue.
Are you sending this email to ask a review and integration of your patch?
I think it should be reviewed by an Intel developer.
Note: it would be good to have the commit reference
Hi Aziz,
Yes, you're right DPDK VMXNET3-PMD in /lib/librte_pmd_vmxnet3 does not support
mbuf chaining today. But it's a standalone bsd driver just like any other pmd
in that directory, it does not need vmxnet3-usermap.ko module.
Now there is another vmxnet3 solution in a separate branch as a pl
Hi Pawel,
> -Original Message-
> From: Wodkowski, PawelX
> Sent: Friday, November 07, 2014 3:05 PM
> To: De Lara Guarch, Pablo; Jastrzebski, MichalX K
> Cc: dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v3 0/2] bond: mode 4 support
>
> > Since Declan sent a v6 for link bonding changes,
Hello Yong,
On 11/07/2014 01:43 AM, Yong Wang wrote:
>>> As to HW TX checksum offload, do you have special requirement for
>>> implementing TSO?
>
>> Yes. TSO implies TX TCP and IP checksum offload.
>
> Is this a general requirement or something specific to ixgbe/i40e? FWIW,
> vmxnet3 device do
Hi Bruce,
Please find my comment in lined.
On Fri, Nov 7, 2014 at 9:00 PM, Bruce Richardson wrote:
> On Fri, Nov 07, 2014 at 08:31:34PM +0530, Manoj Viswanath wrote:
> > Hi Bruce,
> >
> > I was not doing anything specific for binding the NICs to IGB_UIO (like
> > invoking "dpdk_nic_bind.py" scr
> -struct vhost_net_device_ops const *get_virtio_net_callbacks(void);
> +struct vhost_net_device_ops const *get_virtio_net_callbacks(
> + vhost_driver_type_t type);
Tetsuya:
I feel currently it is better we still keep the common
get_virtio_net_callbacks().
For the message flow from c
How about using client/server model and select/poll event handing mechanism
rather than poll?
The polling could cause periodic jitter.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Tetsuya Mukawa
> Sent: Thursday, November 06, 2014 4:15 AM
> To: dev at dpd
According to rss_hf definition in rte_eth_rss_conf, it shall be uint64 type.
Using uint16 will get truncated value, and cause incorrect output. This
fix corrected this issue.
Signed-off-by: Jia Yu
---
app/test-pmd/config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/app/t
1 - 100 of 107 matches
Mail list logo
