Hi,
2014-11-07 16:53, Patel, Rashmin N:
> 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 vmxnet
This patch supports new VMDQ API in vmdq example.
v2 changes:
* code rebase
* allow app to specify num_pools different with max_nb_pools
* fix serious cs issues
Huawei Xie (2):
support new VMDQ API in vmdq example
fix cs issues in vmdq example
examples/vmdq/main.c | 233 +++
This patch supports new VMDQ API in vmdq example.
Besides, it allows users to specify num_pools different with
max_nb_poos, thus the polling thread needn't to poll queues
of all pools.
Due to i40e implmentation issue, there is no default mac for
VMDQ pool, so app needs to specify mac address for
Signed-off-by: Huawei Xie
---
examples/vmdq/main.c | 64 +---
1 file changed, 36 insertions(+), 28 deletions(-)
diff --git a/examples/vmdq/main.c b/examples/vmdq/main.c
index 5a2305f..e60b671 100644
--- a/examples/vmdq/main.c
+++ b/examples/vmdq/ma
">> 5" rather than ">> 4"
Signed-off-by: Huawei Xie
---
lib/librte_pmd_i40e/i40e_ethdev.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/lib/librte_pmd_i40e/i40e_ethdev.c
b/lib/librte_pmd_i40e/i40e_ethdev.c
index 5074262..c0cf3cf 100644
--- a/lib/librte_pmd_i40e/i40e
Add two macros I40E_VFTA_IDX and I40E_VFTA_BIT for VFTA manipulation.
Add vlan_id check in vlan filter search and set function.
Signed-off-by: Huawei Xie
---
lib/librte_pmd_i40e/i40e_ethdev.c | 17 ++---
lib/librte_pmd_i40e/i40e_ethdev.h | 9 +
2 files changed, 19 insertions
This patchset fixes "set vlan filter" issue.
v2 changes:
* add two macros I40E_VFTA_IDX and I40E_VFTA_BIT for VFTA array operation.
Huawei Xie (2):
vlan id set fix
add I40E_VFTA_IDX and I40E_VFTA_BIT macros for VFTA related operation
lib/librte_pmd_i40e/i40e_ethdev.c | 20 ++
I wasn't sure about why anyone would "avoid using UIO just for Virtio even
though other devices need uio/vfio in DPDK." I mean I haven't seen anyone using
that way and performance wise they both are similar.
But anyways here are the major reasons we had Intel versions:
1. Intel Virtio-PMD versio
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Monday, November 10, 2014 8:30 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 0/2] examples/vmdq: support new VMDQ
> API
>
> This patch supports new VMDQ API in vmdq example.
>
>
Hi Huawei
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Monday, November 10, 2014 10:46 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 2/2] lib/librte_pmd_i40e: add I40E_VFTA_IDX and
> I40E_VFTA_BIT macros for VFTA related opera
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Monday, November 10, 2014 10:46 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 1/2] lib/librte_pmd_i40e: set vlan filter fix
>
> ">> 5" rather than ">> 4"
>
> Signed-off-by: Huawe
Hi XIe,
(2014/11/08 6:25), Xie, Huawei wrote:
> How about using client/server model and select/poll event handing mechanism
> rather than poll?
> The polling could cause periodic jitter.
>
Sounds nice. I will change like your comment.
Thanks,
Tetsuya
Hi Xie,
(2014/11/08 5:43), Xie, Huawei wrote:
>> -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
> ge
> -Original Message-
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Wednesday, November 5, 2014 6:28 PM
> To: Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum
> offload
>
> Hi Jijiang,
>
> Thank you for you
> -Original Message-
> From: Zhang, Helin
> Sent: Sunday, November 09, 2014 10:09 PM
> To: Xie, Huawei; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 1/2] lib/librte_pmd_i40e: set vlan filter
> fix
>
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.or
> -Original Message-
> From: Zhang, Helin
> Sent: Sunday, November 09, 2014 10:08 PM
> To: Xie, Huawei; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v2 2/2] lib/librte_pmd_i40e: add I40E_VFTA_IDX
> and I40E_VFTA_BIT macros for VFTA related operation
>
> Hi Huawei
>
> > -Original
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Sunday, November 09, 2014 10:13 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: nakajima.yoshihiro at lab.ntt.co.jp; masutani.hitoshi at lab.ntt.co.jp
> Subject: Re: [dpdk-dev] [RFC PATCH 3/7] lib/librte_vhost:
Hi Nicolas,
> 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. Clearly the white list option is
>
Tetsuya:
I already did this, :), and will publish the code for review after I do some
cleanup next week.
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Sunday, November 09, 2014 10:11 PM
> To: Xie, Huawei; dev at dpdk.org
> Cc: nakajima.yoshihiro at lab.
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Huawei Xie
> Sent: Monday, November 10, 2014 10:46 AM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2 0/2] lib/librte_pmd_i40e: set vlan filter fix
>
> This patchset fixes "set vlan filter" issue.
>
> v
Hi Xie,
(2014/11/10 17:07), Xie, Huawei wrote:
> Here all layer 2 implementations are required to return same type of
> vhost_net_device_ops function pointers to
> layer 1, so layer 1 need to do some kind of preprocessing of its message or
> wrap some private message ctx in like vhost_device_ctx
Hi Xie,
(2014/11/10 17:18), Xie, Huawei wrote:
> Tetsuya:
> I already did this, :), and will publish the code for review after I do some
> cleanup next week.
I appreciate it.
I guess your implementation assumes that all vhost-user functions you
implemented are called
by virtio common layer. Is
Hi Thomas,
> Hi Alan,
>
> Did you make any progress in Qemu/KVM community?
> We need to be sync'ed up with them to be sure we share the same goal.
> I want also to avoid using a solution which doesn't fit with their plan.
> Remember that we already had this problem with ivshmem which was
> planne
> > These references to drivers break the layering isolation between
> > application and
> > drivers.
> >
> > Signed-off-by: Thomas Monjalon
>
> Acked-by: Helin Zhang
> With minor changes suggested: 'devices' -> 'device'?
Applied with suggested changes.
Thanks
--
Thomas
When using test-pmd with flow director in FreeBSD, the application will
segfault/Bus error while parsing the command-line. This is due to how
each commands result structure is represented during parsing, where the offsets
for each tokens value is stored in a character array(char result_buf[BUFSIZ])
Thomas,
This patch is based on 1.7.1. Thought that is the latest. And I got the
diff from origin.
What made you feel that the patch is from 1.7?
Regards,
-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 HEA
> Adding this check is to avoid breakage from future data structure changes.
>
> Signed-off-by: Jia Yu
Excellent idea!
Acked-by: Thomas Monjalon
Applied
Thanks
--
Thomas
> > 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:
Hi Jia,
2014-11-07 09:31, Jia Yu:
> This patch series include a fix and an improvement to rte_ethdev lib.
New enhancements won't be integrated in release 1.8.
But fixes are welcome.
The problem is that it's not easy to track partially applies patchset.
So it would be simpler if you send your fix
2014-11-07 09:28, Jia Yu:
> Include rte_memory.h for lib files that use __rte_cache_aligned
> attribute.
Please could you explain what was the error?
As I suspect it's a fix, it would be clearer to start your title with "fix".
Thanks
--
Thomas
Thomas,
It is our pleasure to be part of the community and to be contributing to
it.
Looking forward to a healthy and fruitful association.
Thanks and Regards,
-Sujith
On 07/11/14 4:39 pm, "Thomas Monjalon" wrote:
>2014-11-08 01:35, Sujith Sankar:
>> ENIC PMD is the poll-mode driver for the Cis
Hi Liang
I don't think that overriding the value passed to pci_map_resource as argument
is the way to go. While it results in less code, it looks weird, in my opinion
at least, as I believe tracking the correctness of address being requested
should be the responsibility of the caller, i.e. eith
Neil,
If I move the DPDK patch that accommodates ENIC PMD (that is the one that
patches lib/Makefile) to the last in the series, builds between commits
would succeed, wouldn?t it? Moving that to the last is anyway needed.
Thanks,
-Sujith
On 07/11/14 9:16 pm, "Sujith Sankar (ssujith)" wrote:
>
It is a default value when the requested_addr isn't exist, not an overide. When
the?pci_map_resource is called at the primary process, the?requested_addr is
NULL. The default value will be provided by?default_map_addr.
When the?pci_map_resource is called at the secondery process,
the?requested_a
2014-11-10 09:27, Sujith Sankar:
> On 07/11/14 9:17 pm, "Thomas Monjalon" wrote:
> >It seems that this PMD is based on DPDK 1.7.
> >Could you rebase it on HEAD?
>
> This patch is based on 1.7.1. Thought that is the latest. And I got the
> diff from origin.
> What made you feel that the patch is
Of course you can take this job. Thanks you for your
help.--From:??
Time:2014 Nov 10 (Mon) 18 : 01To:Burakov, Anatoly
, dev at dpdk.org Cc:thomas.monjalon at 6wind.com Subject:Re: [PATCH] eal: map PCI memory resources after hugepage
Thanks for the clear response. I?ll take a look at it.
Regards,
-Sujith
On 10/11/14 3:33 pm, "Thomas Monjalon" wrote:
>2014-11-10 09:27, Sujith Sankar:
>> On 07/11/14 9:17 pm, "Thomas Monjalon"
>>wrote:
>> >It seems that this PMD is based on DPDK 1.7.
>> >Could you rebase it on HEAD?
>>
>> T
Thomas,
These are files common to all flavours (user-space as well as kernel mode)
of VIC drivers. I shall add this info to the commit logs.
Let me rework the directory structure too.
Thanks,
-Sujith
On 07/11/14 9:21 pm, "Thomas Monjalon" wrote:
>2014-11-08 01:35, Sujith Sankar:
>> lib/librte
User application is advocated to set the newly introduced union field
mbuf->hash.usr as flow id, which is uint32_t.
With introduction of in_flight_bitmask, the whole 32 bits of tag can
be used.
Further more, this patch fixed the integer overflow when finding the
matched tags.
Note that currently
On Fri, Nov 07, 2014 at 11:26:08PM +0530, Manoj Viswanath wrote:
> Hi Bruce,
>
> Please find my comment in lined.
>
> On Fri, Nov 7, 2014 at 9:00 PM, Bruce Richardson intel.com
> > wrote:
>
> > On Fri, Nov 07, 2014 at 08:31:34PM +0530, Manoj Viswanath wrote:
> > > Hi Bruce,
> > >
> > > I was no
On Mon, Nov 10, 2014 at 12:38:32PM +0200, Qinglai Xiao wrote:
> User application is advocated to set the newly introduced union field
> mbuf->hash.usr as flow id, which is uint32_t.
> With introduction of in_flight_bitmask, the whole 32 bits of tag can
> be used.
>
> Further more, this patch fixed
By the way, the?pci_map_resource will check the mapaddr ==?requested_addr. So
you must provide a usable?requested_addr. It's a reason I modified
the?pci_map_resource().--From:??
Time:2014 Nov 10 (Mon) 18 : 04To:Burakov, Anatoly
, d
On Mon, Nov 10, 2014 at 09:59:45AM +, Sujith Sankar (ssujith) wrote:
> Neil,
>
> If I move the DPDK patch that accommodates ENIC PMD (that is the one that
> patches lib/Makefile) to the last in the series, builds between commits
> would succeed, wouldn?t it? Moving that to the last is anyway
Multi-process DPDK application must mmap hugepages and pci resources
into the same virtual address space. By default the virtual addresses
are chosen by the primary process automatically when calling the mmap.
But sometimes the chosen virtual addresses aren't usable in secondary
process - for examp
Hi Oliver,
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Olivier MATZ
> Sent: Friday, November 07, 2014 5:16 PM
> To: Yong Wang; Liu, Jijiang
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v8 10/10] app/testpmd:test VxLAN Tx checksum
> offload
>
> Hello Yong,
>
> On 11/07/20
OK thx Bruce, I will make 2 commits with one cover-letter.
On Mon, Nov 10, 2014 at 1:09 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Mon, Nov 10, 2014 at 12:38:32PM +0200, Qinglai Xiao wrote:
> > User application is advocated to set the newly introduced union field
> > mbuf->
The patch series extends the tags used by librte_distributor from 31 bits to 32
bits. Besides, it fixes the integer overflow in the algorithm of finding matched
tags.
The newly introduced union field rte_mbuf.hash.usr stands as the flow
identifier.
User application is advocated to set this field
This field is added for librte_distributor. User of librte_distributor
is advocated to set value of mbuf->hash.usr before calling
rte_distributor_process. The value of usr is the tag which stands as
identifier of flow.
Signed-off-by: Qinglai Xiao
---
app/test/test_distributor.c |
With introduction of in_flight_bitmask, the whole 32 bits of tag can be
used. Further more, this patch fixed the integer overflow when finding
the matched tags.
Note that currently librte_distributor supports up to 64 worker threads.
If more workers are needed, the size of in_flight_bitmask and the
On Mon, Nov 10, 2014 at 02:52:46PM +0200, Qinglai Xiao wrote:
> This field is added for librte_distributor. User of librte_distributor
> is advocated to set value of mbuf->hash.usr before calling
> rte_distributor_process. The value of usr is the tag which stands as
> identifier of flow.
>
> Signe
Nak, there are issues with the patch. There is another patch already, but I'll
submit it whenever Liang verifies it works with his setup.
Thanks,
Anatoly
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Anatoly Burakov
Sent: Monday, November 10, 2014 11:35 AM
To: d
On Mon, Nov 10, 2014 at 02:52:47PM +0200, Qinglai Xiao wrote:
> With introduction of in_flight_bitmask, the whole 32 bits of tag can be
> used. Further more, this patch fixed the integer overflow when finding
> the matched tags.
> Note that currently librte_distributor supports up to 64 worker thre
Hi,
is it possible to build a dpdk app as a shared library?
I tried to put 'include $(RTE_SDK)/mk/rte.extshared.mk' in my Makefile (and
define SHARED) and it builds .so lib, but all rte_* symbols are undefined.
After that i tried adding:
LDLIBS += -lrte_eal -lrte_mbuf -lrte_cmdline -lrte_timer
With introduction of in_flight_bitmask, the whole 32 bits of tag can be
used. Further more, this patch fixed the integer overflow when finding
the matched tags.
The maximum number workers is now defined as 64, which is length of
double-word. The link between number of workers and RTE_MAX_LCORE is
n
On Mon, Nov 10, 2014 at 04:44:02PM +0200, Qinglai Xiao wrote:
> With introduction of in_flight_bitmask, the whole 32 bits of tag can be
> used. Further more, this patch fixed the integer overflow when finding
> the matched tags.
> The maximum number workers is now defined as 64, which is length of
Hi Bruce,
Sorry I didn't. I will run a performance test tomorrow.
thx &
rgds,
-qinglai
On Mon, Nov 10, 2014 at 5:13 PM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Mon, Nov 10, 2014 at 04:44:02PM +0200, Qinglai Xiao wrote:
> > With introduction of in_flight_bitmask, the whole
Hello Konstantin,
>> By the way, we had the same kind of discussion with Konstantin [1]
>> about what to do with the TCP checksum. My feeling is that setting it
>> to the pseudo-header checksum is the best we can do:
>> - linux does that
>> - many hardware requires that (this is not the case for
This series add TSO support in ixgbe DPDK driver. This is the third
version of the series, but as the previous version [1] was posted several
months ago and included a mbuf rework that is now in mainline, it can
be considered as a new patch series. I'm open to comments on this
patchset, especially
Since commit 4332beee9 "mbuf: expand ol_flags field to 64-bits", the
packet flags are now 64 bits wide. Some occurences were forgotten in
the ixgbe driver.
Signed-off-by: Olivier Matz
---
lib/librte_pmd_ixgbe/ixgbe_rxtx.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff -
The tx mbuf flags are ordered from the highest value to the
the lowest. Move the PKT_TX_VXLAN_CKSUM at the right place.
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/
Describe how to use hardware checksum API.
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.h | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index be15168..96e322b 100644
--- a/lib/lib
This definition is specific to Intel PMD drivers and its definition
"indicate what bits required for building TX context" shows that it
should not be in the generic rte_mbuf.h but in the PMD driver.
Signed-off-by: Olivier Matz
---
lib/librte_mbuf/rte_mbuf.h| 5 -
lib/librte_pmd_e1000
In test-pmd (rxonly.c), the code is able to dump the list of ol_flags.
The issue is that the list of flags in the application has to be
synchronized with the flags defined in rte_mbuf.h.
This patch introduces 2 new functions rte_get_rx_ol_flag_name()
and rte_get_tx_ol_flag_name() that returns the
Implement TSO (TCP segmentation offload) in ixgbe driver. The driver is
now able to use PKT_TX_TCP_SEG mbuf flag and mbuf hardware offload infos
(l2_len, l3_len, l4_len, tso_segsz) to configure the hardware support of
TCP segmentation.
In ixgbe, when doing TSO, the IP length must not be included i
The csum forward engine was becoming too complex to be used and
extended (the next commits want to add the support of TSO):
- no explaination about what the code does
- code is not factorized, lots of code duplicated, especially between
ipv4/ipv6
- user command line api: use of bitmasks that nee
If the user specifies 'set verbose 1' in testpmd command line,
the csum forward engine will dump some informations about received
and transmitted packets, especially which flags are set and what
values are assigned to l2_len, l3_len, l4_len and tso_segsz.
This can help someone implementing TSO or
Add two new commands in testpmd:
- tso set
- tso show
These commands can be used enable TSO when transmitting TCP packets in
the csum forward engine. Ex:
set fwd csum
tx_checksum set ip hw 0
tso set 800 0
start
Signed-off-by: Olivier Matz
---
app/test-pmd/cmdline.c | 92 ++
According to Intel? 82599 10 GbE Controller Datasheet (Table 7-38), both
L2 and L3 lengths are needed to offload the IP checksum.
Note that the e1000 driver does not need to be patched as it already
contains the fix.
Signed-off-by: Olivier Matz
Acked-by: Konstantin Ananyev
---
lib/librte_pmd_e
In testpmd the rte_port->tx_ol_flags flag was used in 2 incompatible
manners:
- sometimes used with testpmd specific flags (0xff for checksums, and
bit 11 for vlan)
- sometimes assigned to m->ol_flags directly, which is wrong in case
of checksum flags
This commit replaces the hardcoded values
Some of the NICs supported by DPDK have a possibility to accelerate TCP
traffic by using segmentation offload. The application prepares a packet
with valid TCP header with size up to 64K and deleguates the
segmentation to the NIC.
Implement the generic part of TCP segmentation offload in rte_mbuf.
Hi Jijiang,
On 11/10/2014 07:03 AM, Liu, Jijiang wrote:
>> Another thing is surprising me.
>>
>> - if PKT_TX_VXLAN_CKSUM is not set (legacy use case), then the
>>driver use l2_len and l3_len to offload inner IP/UDP/TCP checksums.
> If the flag is not set, and imply that it is not VXLAN packet,
On Mon, Nov 10, 2014 at 05:52:26PM +0200, jigsaw wrote:
> Hi Bruce,
>
> Sorry I didn't. I will run a performance test tomorrow.
>
> thx &
> rgds,
> -qinglai
>
On the assumption that no performance regressions show up...
Acked-by: Bruce Richardson
> On Mon, Nov 10, 2014 at 5:13 PM, Bruce Rich
On Mon, Nov 10, 2014 at 04:59:16PM +0100, Olivier Matz wrote:
> Since commit 4332beee9 "mbuf: expand ol_flags field to 64-bits", the
> packet flags are now 64 bits wide. Some occurences were forgotten in
> the ixgbe driver.
>
> Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
> ---
> li
On Mon, Nov 10, 2014 at 04:59:17PM +0100, Olivier Matz wrote:
> The tx mbuf flags are ordered from the highest value to the
> the lowest. Move the PKT_TX_VXLAN_CKSUM at the right place.
>
> Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
> ---
> lib/librte_mbuf/rte_mbuf.h | 4 ++--
> 1
On Mon, Nov 10, 2014 at 04:59:18PM +0100, Olivier Matz wrote:
> Describe how to use hardware checksum API.
>
> Signed-off-by: Olivier Matz
Acked-by: Bruce Richardson
> ---
> lib/librte_mbuf/rte_mbuf.h | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff
On Mon, Nov 10, 2014 at 04:59:19PM +0100, Olivier Matz wrote:
> This definition is specific to Intel PMD drivers and its definition
> "indicate what bits required for building TX context" shows that it
> should not be in the generic rte_mbuf.h but in the PMD driver.
>
> Signed-off-by: Olivier Matz
On Mon, Nov 10, 2014 at 04:59:20PM +0100, Olivier Matz wrote:
> In test-pmd (rxonly.c), the code is able to dump the list of ol_flags.
> The issue is that the list of flags in the application has to be
> synchronized with the flags defined in rte_mbuf.h.
>
> This patch introduces 2 new functions r
> From: Carew, Alan
>
> > Did you make any progress in Qemu/KVM community?
> > We need to be sync'ed up with them to be sure we share the same goal.
> > I want also to avoid using a solution which doesn't fit with their plan.
> > Remember that we already had this problem with ivshmem which was
> >
Hi Bruce,
Thank you for the review.
On 11/10/2014 06:29 PM, Bruce Richardson wrote:
>> +/**
>> + * Bit Mask to indicate what bits required for building TX context
>
> I don't understand this first line - is it accidentally included?
Right, it's a mistake, I'll remove this line.
>> + * Get the
Hi Bruce,
On 11/10/2014 06:14 PM, Bruce Richardson wrote:
>> --- a/lib/librte_pmd_e1000/igb_rxtx.c
>> +++ b/lib/librte_pmd_e1000/igb_rxtx.c
>> @@ -400,7 +400,8 @@ eth_igb_xmit_pkts(void *tx_queue, struct rte_mbuf
>> **tx_pkts,
>> ol_flags = tx_pkt->ol_flags;
>> vlan_maci
Rashmin,
Since I do need the jumbo, I use the vmxnet3-plugin you described, i.e.
(1)
sudo insmod ./vmxnet3-usermap.ko enable_shm=2,2 num_rqs=1,1 num_rxds=2048
num_txds=2048
and (2) when running the application, use in the args list:
"-d", "librte_pmd_vmxnet3.so"
Does the above two piece mean vmxne
On Mon, Nov 10, 2014 at 03:22:40PM +0100, Newman Poborsky wrote:
> is it possible to build a dpdk app as a shared library?
Yes it will work, with a bit of performance loss from the .so symbol lookup
overhead. You have to set some of the build config options to get it to work
though.
Matthew.
82 matches
Mail list logo
