On 2015/04/23 17:12, Iremonger, Bernard wrote:
>
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Thursday, April 23, 2015 5:24 AM
>> To: Iremonger, Bernard; dev at dpdk.org
>> Cc: Richardson, Bruce; david.marchand at 6wind.com
>> Subject: Re: [PATCH v3 0
On 22 April 2015 at 18:33, Huawei Xie wrote:
> update of used->idx and read of avail->flags could be reordered.
> memory fence should be used to ensure the order, otherwise guest could see
> a stale used->idx value after it toggles the interrupt suppression flag.
>
This patch looks right to me.
pcap_rx_queue/pcap_tx_queue should store it's own copy of name/type values,
not the pointer to temporary allocated space.
Signed-off-by: Konstantin Ananyev
---
lib/librte_pmd_pcap/rte_eth_pcap.c | 51 +-
1 file changed, 34 insertions(+), 17 deletions(-)
diff
On Thu, Apr 23, 2015 at 7:00 AM, Bruce Richardson <
bruce.richardson at intel.com> wrote:
> On Thu, Apr 23, 2015 at 06:53:44AM -0700, Ravi Kerur wrote:
> > On Thu, Apr 23, 2015 at 2:23 AM, Ananyev, Konstantin <
> > konstantin.ananyev at intel.com> wrote:
> >
> > >
> > >
> > > > -Original Messa
2015-04-23 13:49, Bruce Richardson:
> There are no memcpy functions in rte_ip.h so there is no need to include
> rte_memcpy.h in that file.
>
> Signed-off-by: Bruce Richardson
Applied, thanks
On Thu, Apr 23, 2015 at 06:53:44AM -0700, Ravi Kerur wrote:
> On Thu, Apr 23, 2015 at 2:23 AM, Ananyev, Konstantin <
> konstantin.ananyev at intel.com> wrote:
>
> >
> >
> > > -Original Message-
> > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > > Sent: Thurs
2015-04-17 07:12, Neil Horman:
> On Thu, Apr 16, 2015 at 04:23:38PM -0700, Stephen Hemminger wrote:
> > More places where PCI code should be using const but wasn't
> >
> > Stephen Hemminger (2):
> > pci: make device_id tables const
> > pci: allow const for rte_pci_addr
>
> For the series
> Ac
Changes in v7
Rebase to latest code.
Changes in v6
Split changes due to complexity. v6 includes moving
rte_eal_pci_probe_one_driver function and its associated
utility functions only.
Changes in v5
Rebase to latest code.
Removed RTE_EXEC_ENV_BSDAPP from earlier changes.
Changes in v4
Move common
Changes in v7
None
Changes in v6
Removed unnecessary comments in function declaration.
Changes in v5
Rebase to latest code.
Changes in v4
Make rte_eal_hugepage_init and rte_eal_hugepage_attach as
wrapper functions for BSD.
Changes in v3
Changed subject to be more explicit on file name inclusion
Changes in v7
None
Changes in v6
Added new line between Copyright and header file inclusion
in eal_common_timer.c.
Changes in v5
Rebase to latest code.
Changes in v4
Removed extern declaration of eal_tsc_resolution_hz,
instead provided _set_ API.
Make set_tsc_freq_from_clock as wrapper function
Changes in v7
None
Changes in v6
None
Changes in v5
Rebase to latest code.
Changes in v4
Implement cpu_detected() for BSD.
Have common RTE_LOG for Linux and BSD in rte_eal_cpu_init().
Remove RTE_EXEC_ENV_BSDAPP in common file.
Changes in v3
Changed subject to be more explicit on file name inclu
Changes in v7
Fix clang and ICC compilation errors.
Changes in v6
Split eal_common_system.c and eal_common_runtime.c into
eal_common_sysfs.c
eal_common_mem_cfg.c
eal_common_proc_type.c
eal_comm_app_usage.c
based on functionality.
Changes in v5
Rebase to latest code.
Changes in v4
Remove eal_exte
Changes in v7
Remove _setname_ pthread calls.
Use rte_gettid() API in RTE_LOG to print thread_id.
Changes in v6
Remove RTE_EXEC_ENV_BSDAPP from eal_common_thread.c file.
Add pthread_setname_np/pthread_set_name_np for Linux/FreeBSD
respectively. Plan to use _getname_ in RTE_LOG when available.
Use
Changes in v7 includes
Fix clang and ICC compilation errors reported by Bruce.
Remove pthread _setname_ APIs introduced in v6 as a separate
patch is sent.
Testing:
Linux - Ubuntu x86_64 14.04
Compilation successful (x86_64-native-linuxapp-gcc
and x86_64-native-linuxapp-clang).
"make test" results
The virtio_net header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward
The rte_table header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward
The virtqueue header files include the mbuf header file, but they do not
need to do so as they only use pointers to the struct rte_mbuf type, and
do not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward d
The pipeline header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward d
The ip_frag header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward de
The kni header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward declar
The ethdev header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forward dec
The distributor header file includes the mbuf header file, but it does not
need to do so as it only uses pointers to the struct rte_mbuf type, and
does not use any of the mbuf internals, nor any of the mbuf functions or
macros. Therefore the inclusion is unnecessary, and can be replaced by a
forwar
A large number of our header files and libraries are dependent on one another,
which can lead to problems with circular dependencies if trying to tie some of
those libraries together, e.g. when prototyping with pktdev, or other schemes
to get a common API for ethdev/rings/KNI. :-)
One small way t
On Apr 23, 2015 12:20 PM, "Ananyev, Konstantin" <
konstantin.ananyev at intel.com> wrote:
>
> Argh, yep my bad - somehow missed that ixgbe/ixgbe_type.h was modified.
> Yep, I suppose it has to be fixed asap.
> Vlad, can you provide a patch and move it into struct ixgbe_adapter, as
was suggested?
There are no memcpy functions in rte_ip.h so there is no need to include
rte_memcpy.h in that file.
Signed-off-by: Bruce Richardson
---
lib/librte_net/rte_ip.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/librte_net/rte_ip.h b/lib/librte_net/rte_ip.h
index 74c9ced..cdbce20 100644
--- a
On 2015/04/21 22:15, Iremonger, Bernard wrote:
>> -Original Message-
>> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
>> Sent: Friday, March 27, 2015 8:39 AM
>> To: dev at dpdk.org
>> Cc: Iremonger, Bernard; Richardson, Bruce; david.marchand at 6wind.com;
>> Tetsuya Mukawa
>> Subject:
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
>
> This does a good job of stating the need for action without getting into the
> details.
> Perhaps this would be better resolved by some more interactive discussion.
> I know it is hard to all get together, but there needs to be
A non-text attachment was scrubbed...
Name: DPDK_QoS_Readout_20150421.pdf
Type: application/pdf
Size: 761274 bytes
Desc: DPDK_QoS_Readout_20150421.pdf
URL:
<http://dpdk.org/ml/archives/dev/attachments/20150423/17a4d8de/attachment-0001.pdf>
> From: Vladislav Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Thursday, April 23, 2015 12:02 PM
> To: Ananyev, Konstantin
> Cc: Zhang, Helin; dev at dpdk.org
> Subject: RE: [dpdk-dev] [PATCH v8 0/3]: Add LRO support to ixgbe PMD
>
>
> On Apr 23, 2015 12:20 PM, "Ananyev, Konstantin"
On 23 April 2015 at 10:11, Bruce Richardson
wrote:
> Also, if I read your quoted performance numbers in your earlier mail
> correctly,
> we are only looking at a 1-4% performance increase. Is the additional code
> to
> maintain worth the benefit?
>
... and if so, how would one decide whether it
On 2015-04-22 17:33, Ravi Kerur wrote:
> +/**
> + * Compare bytes between two locations. The locations must not overlap.
> + *
> + * @note This is implemented as a macro, so it's address should not be taken
> + * and care is needed as parameter expressions may be evaluated multiple
> times.
> + *
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Thursday, April 23, 2015 9:12 AM
> To: Wodkowski, PawelX
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] Implement memcmp using AVX/SSE instructio
>
> On Thu, Apr 23, 2015 at 0
Argh, yep my bad - somehow missed that ixgbe/ixgbe_type.h was modified.
Yep, I suppose it has to be fixed asap.
Vlad, can you provide a patch and move it into struct ixgbe_adapter, as was
suggested?
Thanks
Konstantin
> -Original Message-
> From: Zhang, Helin
> Sent: Thursday, April 23,
On Wed, Apr 22, 2015 at 03:57:44PM -0700, Stephen Hemminger wrote:
> On Wed, 22 Apr 2015 14:05:48 -0700
> Ravi Kerur wrote:
>
> > Add code to set names to threads via pthread APIs.
> > In Linux corresponding _getname_ is available, however, FreeBSD
> > doesn't have corresponding _get_name API ava
On Thu, Apr 23, 2015 at 09:24:52AM +0200, Pawel Wodkowski wrote:
> On 2015-04-22 17:33, Ravi Kerur wrote:
> >+/**
> >+ * Compare bytes between two locations. The locations must not overlap.
> >+ *
> >+ * @note This is implemented as a macro, so it's address should not be taken
> >+ * and care is ne
Hi Stephen,
> What we ended up doing is a second patch to have a "compat_vfio.h" file to
> allow building on older systems. I will send that as a follow on.
I would argue it should be part of this series, as without them the patch
breaks compilation on older kernels.
> The problem is compounded
Tested-by:huilong xu
- Tested Commit: 0095bb6dd77a6b4570af27320187e63bf37500c6
- OS: FC20 3.11.10-301.fc20.x86_64
- GCC: gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)
- CPU: Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
- NIC: Ethernet controller [0200]: Intel Corporation Ethernet Controlle
> -Original Message-
> From: Tetsuya Mukawa [mailto:mukawa at igel.co.jp]
> Sent: Thursday, April 23, 2015 5:24 AM
> To: Iremonger, Bernard; dev at dpdk.org
> Cc: Richardson, Bruce; david.marchand at 6wind.com
> Subject: Re: [PATCH v3 0/5] Clean up pci uio implementations
>
> On 2015/04/
On Thu, Apr 23, 2015 at 2:23 AM, Ananyev, Konstantin <
konstantin.ananyev at intel.com> wrote:
>
>
> > -Original Message-
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> > Sent: Thursday, April 23, 2015 9:12 AM
> > To: Wodkowski, PawelX
> > Cc: dev at dpdk.or
On Thu, Apr 23, 2015 at 12:24 AM, Pawel Wodkowski <
pawelx.wodkowski at intel.com> wrote:
> On 2015-04-22 17:33, Ravi Kerur wrote:
>
>> +/**
>> + * Compare bytes between two locations. The locations must not overlap.
>> + *
>> + * @note This is implemented as a macro, so it's address should not be
BTW, the BIOS fix has been posted for the NUMA node reporting issue in Linux
kernel when COD is disabled. Now the /sys/devices/*/*/numa_node will provide
you the correct information.
Regards
Kannan Babu
-Original Message-
From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Bruce Richar
update of used->idx and read of avail->flags could be reordered.
memory fence should be used to ensure the order, otherwise guest could see a
stale used->idx value after it toggles the interrupt suppression flag.
Signed-off-by: Huawei Xie
---
lib/librte_vhost/vhost_rxtx.c | 3 +++
1 file change
Vlad
OK. Thanks! We will try to see if a follow up patch set can be submitted soon.
Regards,
Helin
> -Original Message-
> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
> Sent: Wednesday, April 22, 2015 5:19 PM
> To: Zhang, Helin; dev at dpdk.org
> Cc: Ananyev, Konstantin
>
43 matches
Mail list logo
