Acked-by: Helin Zhang
With minor changes suggested: 'devices' -> 'device'?
> -Original Message-
> From: Thomas Monjalon [mailto:thomas.monjalon at 6wind.com]
> Sent: Friday, November 7, 2014 8:49 PM
> To: dev at dpdk.org
> Cc: Zhang, Helin
> Subject: [PATCH] app,examples: remove referenc
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
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
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
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
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
> -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
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
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
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.
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!
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
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
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,
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
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;
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
Sujith,
It seems that this PMD is based on DPDK 1.7.
Could you rebase it on HEAD?
Thank you
--
Thomas
> -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
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
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
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 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
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
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
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
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 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
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
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
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 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
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
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
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
> 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)
> <
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
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 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
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
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 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
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
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
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
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
> -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
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
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
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
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).
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
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
>
> 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
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,
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,
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
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
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
---
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
---
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
> 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
> -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
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
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
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
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
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
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
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
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
Adding this check is to avoid breakage from future data structure changes.
Signed-off-by: Jia Yu
---
lib/librte_kni/rte_kni.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/lib/librte_kni/rte_kni.c b/lib/librte_kni/rte_kni.c
index 31ecb33..f5c449c 100644
--- a/lib/librte_kn
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
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 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
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
Before the fix, bond device's offload capabilities are unset. This fix
takes the minimum common set of slave devices' capabilities as bond
device's capabilities. For simplicity, we ensure all slave devices
to have a capability before bond device can claim this capability,
even if some slave devices
rte_eth_stats_get is to get physical device statistics. Without
return status, caller does not know whether function fails or not
(i.e. invalid port_id, driver has no stats_get callback). Caller
cannot differiente normal 0 stats or error case. This fix adds
a return status to the function.
Signed-
Since LSR interrupt is disabled by pmd drivers, link status in rte_eth_device
is always down.
Bond slave_configure() enables LSR interrupt on devices to get notification if
link status
changes. However, the LSC interrupt at device start time is still lost.
In this fix, call link_update to read l
This patch series include a fix and an improvement to rte_ethdev lib.
Jia Yu (2):
rte_ethdev: update link status (speed, duplex, link_up) after
rte_eth_dev_start
rte_ethdev: add return status for rte_eth_stats_get
lib/librte_ether/rte_ethdev.c | 11 ---
lib/librte_ether/rte_ethde
Include rte_memory.h for lib files that use __rte_cache_aligned
attribute.
Signed-off-by: Jia Yu
---
lib/librte_distributor/rte_distributor.c| 1 +
lib/librte_eal/common/include/rte_malloc_heap.h | 1 +
lib/librte_ip_frag/rte_ip_frag.h| 1 +
lib/librte_malloc/malloc_elem.
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
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.
> >
>
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
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
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
> ""
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
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: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/
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
> -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
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
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
1 - 100 of 107 matches
Mail list logo
