Thanks, it makes sense. I'll get around to it "eventually".
On Thu, 2023-11-02 at 11:04 +0100, Thomas Monjalon wrote:
> Hello,
>
> While looking at Seastar, I see it uses this patch on top of DPDK:
>
> build: add meson options of max_memseg_lists
>
> RTE_MAX_MEMSEG_LISTS = 128 i
On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
> On 08/04/2015 19:26, Stephen Hemminger wrote:
>> On Wed, 8 Apr 2015 16:07:21 +0100
>> Sergio Gonzalez Monroy wrote:
>>
>>> Currently, the target/rules to build combined libraries is different
>>> than the one to build individual libraries
On 04/09/2015 02:19 PM, Neil Horman wrote:
> On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote:
>>
>> On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote:
>>> On 08/04/2015 19:26, Stephen Hemminger wrote:
>>>> On Wed, 8 Apr 2015 16:07:21 +010
On 01/04/2017 09:41 PM, Thomas Monjalon wrote:
2016-12-23 19:40, Tomasz Kulasek:
v15 changes:
- marked rte_eth_tx_prepare api as experimental
- improved doxygen comments for nb_seg_max and nb_mtu_seg_max fields
- removed unused "uint8_t tx_prepare" declaration from testpmd
No you didn't r
C++ doesn't allow implied casting from void * to another pointer, so
supply an explicit cast.
Signed-off-by: Avi Kivity
---
lib/librte_mbuf/rte_mbuf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index c3
C++ doesn't allow implied casting from void * to another pointer, so
supply an explicit cast.
Signed-off-by: Avi Kivity
---
lib/librte_mempool/rte_mempool.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/librte_mempool/rte_mempool.h b/lib/librte_me
(adding list+Thomas back to cc)
On 08/17/2015 11:33 AM, Olivier MATZ wrote:
> Hi,
>
> On 08/14/2015 10:33 AM, Avi Kivity wrote:
>> C++ doesn't allow implied casting from void * to another pointer, so
>> supply an explicit cast.
>>
>> Signed-off-by: Avi Kivit
On 08/25/2015 08:33 PM, Ananyev, Konstantin wrote:
> Hi Vlad,
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Thursday, August 20, 2015 10:07 AM
>> To: Ananyev, Konstantin; Lu, Wenzhuo
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v
On 08/25/2015 10:16 PM, Zhang, Helin wrote:
>
>> -Original Message-
>> From: Vlad Zolotarov [mailto:vladz at cloudius-systems.com]
>> Sent: Tuesday, August 25, 2015 11:53 AM
>> To: Zhang, Helin
>> Cc: Lu, Wenzhuo; dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH v1] ixgbe_pmd: forbid tx_rs
On 07/06/2015 04:28 PM, leeopop wrote:
> Some NICs use host memory region as their scratch area.
> When DPDK user applications terminate, all the memory regions are lost,
> re-initialized (memzone), which causes HW faults.
> This libraray maintains shared memory regions that is persistent across
>
The 'register' keyword does nothing, and has been removed in C++17.
Remove it for compatibility.
Signed-off-by: Avi Kivity
---
lib/librte_eal/common/include/arch/arm/rte_byteorder.h | 2 +-
lib/librte_eal/common/include/arch/x86/rte_byteorder.h | 4 ++--
2 files changed, 3 insert
The 'register' keyword does nothing, and has been removed in C++17.
Remove it for compatibility, like commit 0d5f2ed12f9eb.
Signed-off-by: Avi Kivity
---
lib/librte_eal/common/include/arch/x86/rte_byteorder_64.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/
On 01/15/2018 08:00 PM, Thomas Monjalon wrote:
15/01/2018 12:33, Avi Kivity:
The 'register' keyword does nothing, and has been removed in C++17.
Remove it for compatibility, like commit 0d5f2ed12f9eb.
Fixes: 0d5f2ed12f9e ("eal: remove use of register keyword")
Signe
On 06/16/2017 08:40 AM, Shreyansh Jain wrote:
From: Hemant Agrawal
Bit Swap and LE<=>BE conversions for 23, 40 and 48 bit width
Signed-off-by: Hemant Agrawal
---
.../common/include/generic/rte_byteorder.h | 78 ++
1 file changed, 78 insertions(+)
diff --git a
On 01/27/2016 06:24 PM, Ferruh Yigit wrote:
> This kernel module is based on KNI module, but this one is stripped
> version of it and only for control messages, no data transfer
> functionality provided.
>
> This Linux kernel module helps userspace application create virtual
> interfaces and when a
On 02/28/2016 10:16 PM, Ferruh Yigit wrote:
> On 2/28/2016 3:34 PM, Avi Kivity wrote:
>> On 01/27/2016 06:24 PM, Ferruh Yigit wrote:
>>> This kernel module is based on KNI module, but this one is stripped
>>> version of it and only for control messages, no data transfer
On 02/29/2016 12:43 PM, Ferruh Yigit wrote:
> On 2/29/2016 9:43 AM, Avi Kivity wrote:
>> On 02/28/2016 10:16 PM, Ferruh Yigit wrote:
>>> On 2/28/2016 3:34 PM, Avi Kivity wrote:
>>>> On 01/27/2016 06:24 PM, Ferruh Yigit wrote:
>>>>> This kernel m
On 02/29/2016 01:27 PM, Ferruh Yigit wrote:
> On 2/29/2016 10:58 AM, Avi Kivity wrote:
>>
>> On 02/29/2016 12:43 PM, Ferruh Yigit wrote:
>>> On 2/29/2016 9:43 AM, Avi Kivity wrote:
>>>> On 02/28/2016 10:16 PM, Ferruh Yigit wrote:
>>>>> On 2/28/2
On 02/23/2015 11:16 PM, Matthew Hall wrote:
> On Mon, Feb 23, 2015 at 08:48:57AM -0600, Matt Laswell wrote:
>> Apologies in advance for likely being a bit long-winded.
> Long winded is great, helps me get context.
>
>> First, you really need to take cache performance into account when you're
>> cho
On 03/04/2015 02:33 AM, Stephen Hemminger wrote:
> On Tue, 3 Mar 2015 21:48:43 +0200
> Vlad Zolotarov wrote:
>
>> + * TODO:
>> + *- Get rid of "volatile" crap and let the compiler do its
>> + * job.
>> + *- Use the proper memory barri
On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim
wrote:
> Does anybody have any input or comments on this?
>
>
> > -Original Message-
> > From: O'Driscoll, Tim
> > Sent: Thursday, April 16, 2015 11:39 AM
> > To: dev at dpdk.org
> > Subject: Beyond DPDK 2.0
> >
> > Following the launch of
On 05/07/2015 06:27 PM, Wiles, Keith wrote:
>
> On 5/7/15, 7:02 AM, "Avi Kivity" wrote:
>
>> On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim
>>
>> wrote:
>>
>>> Does anybody have any input or comments on this?
>>>
>&g
On 05/07/2015 06:27 PM, Wiles, Keith wrote:
>
> On 5/7/15, 7:02 AM, "Avi Kivity" wrote:
>
>> On Wed, Apr 22, 2015 at 6:11 PM, O'Driscoll, Tim
>>
>> wrote:
>>
>>> Does anybody have any input or comments on this?
>>>
>&g
On 05/07/2015 06:49 PM, Wiles, Keith wrote:
>
> On 5/7/15, 8:33 AM, "Avi Kivity" wrote:
>
>> On 05/07/2015 06:27 PM, Wiles, Keith wrote:
>>> On 5/7/15, 7:02 AM, "Avi Kivity" wrote:
>>>
>>>> On Wed, Apr 22, 2015 at 6:11 PM, O'
On 10/06/2015 10:33 AM, Stephen Hemminger wrote:
> Other than implementation objections, so far the two main arguments
> against this reduce to:
>1. If you allow UIO ioctl then it opens an API hook for all the crap out
> of tree UIO drivers to do what they want.
>2. If you allow UIO M
On 10/06/2015 05:07 PM, Michael S. Tsirkin wrote:
> On Tue, Oct 06, 2015 at 03:15:57PM +0300, Avi Kivity wrote:
>> btw, (2) doesn't really add any insecurity. The user could already poke at
>> the msix tables (as well as perform DMA); they just couldn't get a useful
On 10/10/2015 02:19 AM, Wiles, Keith wrote:
> Here are some notes from the DPDK Network Stack discussion, I can remember
> please help me fill in anything I missed.
>
> Items I remember we talked about:
>
>* The only reason for a DPDK TCP/IP stack is for performance and
> possibly lower lat
On 09/01/2015 05:47 PM, Matthew Hall wrote:
> On Tue, Sep 01, 2015 at 04:37:18PM +0200, Martin Dra?ar wrote:
>> Dne 1.9.2015 v 15:45 De Lara Guarch, Pablo napsal(a):
>>> 82574L NIC uses em PMD, which does not support more than 1 queue.
>>> Therefore RSS is disabled in the NIC and then you cannot ha
On 09/11/2015 05:25 PM, didier.pallard wrote:
> On 08/25/2015 08:52 PM, Vlad Zolotarov wrote:
>>
>> Helin, the issue has been seen on x540 devices. Pls., see a chapter
>> 7.2.1.1 of x540 devices spec:
>>
>> A packet (or multiple packets in transmit segmentation) can span any
>> number of
>> buffe
On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
>
>
> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" <mailto:thomas.monjalon at 6wind.com>> wrote:
> >
> > 2015-09-11 17:47, Avi Kivity:
> > > On 09/11/2015 05:25 PM, didier.pallard wrote:
>
On 09/11/2015 07:07 PM, Richardson, Bruce wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Vladislav Zolotarov
>> Sent: Friday, September 11, 2015 5:04 PM
>> To: Avi Kivity
>> Cc: dev at dpdk.org
>> Subje
On 09/11/2015 07:08 PM, Thomas Monjalon wrote:
> 2015-09-11 18:43, Avi Kivity:
>> On 09/11/2015 06:12 PM, Vladislav Zolotarov wrote:
>>> On Sep 11, 2015 5:55 PM, "Thomas Monjalon" >> <mailto:thomas.monjalon at 6wind.com>> wrote:
>>>> 201
On 09/13/2015 02:47 PM, Ananyev, Konstantin wrote:
>
>> -Original Message-
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Avi Kivity
>> Sent: Friday, September 11, 2015 6:48 PM
>> To: Thomas Monjalon; Vladislav Zolotarov; didier.pallard
>> C
On Sep 13, 2015 6:54 PM, "Ananyev, Konstantin"
wrote:
>
>
>
> > -Original Message-
> > From: Avi Kivity [mailto:avi at cloudius-systems.com]
> > Sent: Sunday, September 13, 2015 1:33 PM
> > To: Ananyev, Konstantin; Thomas Monjalon; Vladisl
On 07/21/2016 06:24 PM, Tomasz Kulasek wrote:
> This is an ABI deprecation notice for DPDK 16.11 in librte_ether about
> changes in rte_eth_dev and rte_eth_desc_lim structures.
>
> As discussed in that thread:
>
> http://dpdk.org/ml/archives/dev/2015-September/023603.html
>
> Different NIC models d
On 07/28/2016 02:38 PM, Jerin Jacob wrote:
> On Thu, Jul 28, 2016 at 10:36:07AM +, Ananyev, Konstantin wrote:
>>> If it does not cope up then it can skip tx'ing in the actual tx burst
>>> itself and move the "skipped" tx packets to end of the list in the tx
>>> burst so that application can t
On 11/16/2015 07:06 PM, Alex Williamson wrote:
> On Wed, 2015-10-28 at 15:21 -0600, Alex Williamson wrote:
>> There is really no way to safely give a user full access to a DMA
>> capable device without an IOMMU to protect the host system. There is
>> also no way to provide DMA translation, for use
On 10/01/2015 11:44 AM, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote:
>>> And for what, to prevent
>>> root from touching memory via dma that they can access in a million other
>>> ways?
>> So one can be reasonably sure a kernel oops is not a resu
On 10/01/2015 11:52 AM, Avi Kivity wrote:
>
>
> On 10/01/2015 11:44 AM, Michael S. Tsirkin wrote:
>> On Wed, Sep 30, 2015 at 11:40:16PM +0300, Michael S. Tsirkin wrote:
>>>> And for what, to prevent
>>>> root from touching memory via dma that they can acce
On 10/01/2015 12:15 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 11:52:26AM +0300, Avi Kivity wrote:
>> I still don't understand your objection to the patch:
>>
>>
>> MSI messages are memory writes so any generic device capable
>>
On 10/01/2015 12:29 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:15:49PM +0300, Avi Kivity wrote:
>> What userspace can't be allowed to do:
>>
>> access BAR
>> write rings
>>
>>
>>
>>
>>
On 10/01/2015 12:42 PM, Vincent JARDIN wrote:
> On 01/10/2015 11:22, Avi Kivity wrote:
>>> As far as I could see, without this kind of motivation, people do not
>>> even want to try.
>>
>> You are mistaken. The problem is a lot harder than you think.
>>
On 10/01/2015 12:42 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
>> even when they are some users
>> prefer to avoid the performance penalty.
> I don't think there's a measureable penalty from passing through the
>
On 10/01/2015 12:48 PM, Vincent JARDIN wrote:
> On 01/10/2015 11:43, Avi Kivity wrote:
>>
>> That is because the device itself contains an iommu.
>
> Yes.
>
> It could be an option:
> - we could flag the Linux system unsafe when the device does not
> have
On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
>> It's easy to claim that
>> a solution is around the corner, only no one was looking for it, but the
>> reality is that kernel bypass has been a s
On 10/01/2015 01:07 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:38:51PM +0300, Avi Kivity wrote:
>> The sad thing is that you can do this since forever on a non-virtualized
>> system, or on a virtualized system if you don't need interrupt support. All
>>
On 10/01/2015 01:14 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:43:53PM +0300, Avi Kivity wrote:
>>> There were some tentative to get it for other (older) drivers, named
>>> 'bifurcated drivers', but it is stalled.
>> IIRC they still exposed th
On 10/01/2015 01:17 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote:
>> Non-virtualized setups have an iommu available, but they can also use
>> pci_uio_generic without patching if they like.
> Not with VFs, they can't.
>
They
On 10/01/2015 01:24 PM, Avi Kivity wrote:
> On 10/01/2015 01:17 PM, Michael S. Tsirkin wrote:
>> On Thu, Oct 01, 2015 at 12:53:14PM +0300, Avi Kivity wrote:
>>> Non-virtualized setups have an iommu available, but they can also use
>>> pci_uio_generic without patchin
On 10/01/2015 01:38 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 12:59:47PM +0300, Avi Kivity wrote:
>>
>> On 10/01/2015 12:55 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 01, 2015 at 12:22:46PM +0300, Avi Kivity wrote:
>>>> It's easy to
On 10/01/2015 01:44 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 01:25:17PM +0300, Avi Kivity wrote:
>> Why use a VF on a non-virtualized system?
> 1. So a userspace bug does not destroy your hardware
> (PFs generally assume trusted non-buggy drivers, VFs
>
On 10/01/2015 01:28 AM, Stephen Hemminger wrote:
> This is a new UIO device driver to allow supporting MSI-X and MSI devices
> in userspace. It has been used in environments like VMware and older versions
> of QEMU/KVM where no IOMMU support is available.
Why not add msi/msix support to uio_pci_g
On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote:
>>>> It's not just the lack of system calls, of course, the architecture is
>>>> completely different.
>>> Absolutely - I'm not saying mov
On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
>> People will just use out of tree drivers (dpdk has several already). It's a
>> pain, but nowhere near what you are proposing.
> What's the issue with tha
On 10/01/2015 02:31 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
>>
>> On 10/01/2015 02:09 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 01, 2015 at 01:50:10PM +0300, Avi Kivity wrote:
>>>>>> It's no
On 10/01/2015 06:01 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 14:32:19 +0300
> Avi Kivity wrote:
>
>> On 10/01/2015 02:27 PM, Michael S. Tsirkin wrote:
>>> On Thu, Oct 01, 2015 at 02:20:37PM +0300, Avi Kivity wrote:
>>>> People will just use out of tr
On 10/01/2015 06:11 PM, Michael S. Tsirkin wrote:
> On Thu, Oct 01, 2015 at 02:32:19PM +0300, Avi Kivity wrote:
>>> We already agreed this kernel
>>> is going to be tainted, and unsupportable.
>> Yes. So your only motivation in rejecting the patch is to get the
On 07/30/2015 07:17 PM, Stephen Hemminger wrote:
> On Thu, 30 Jul 2015 17:57:33 +0300
> Vlad Zolotarov wrote:
>
>> Hi, Konstantin, Helin,
>> there is a documented limitation of xl710 controllers (i40e driver)
>> which is not handled in any way by a DPDK driver.
>> From the datasheet chapter 8.
On 07/30/2015 08:01 PM, Stephen Hemminger wrote:
> On Thu, 30 Jul 2015 19:50:27 +0300
> Vlad Zolotarov wrote:
>
>>
>> On 07/30/15 19:20, Avi Kivity wrote:
>>>
>>> On 07/30/2015 07:17 PM, Stephen Hemminger wrote:
>>>> On Thu, 30 Jul 2015 17:57
Hello dpdk-ers,
We are pleased to announce Scylla, a new open-source NoSQL database
powered by DPDK. Scylla's performance (one million transactions per
second per node) derives in part from a user-space TCP/IP stack, using
DPDK to drive the network cards.
Scylla is open source and can be foun
On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote:
>>
>> On 09/30/15 15:03, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 02:53:19PM +0300, Vlad Zolotarov wrote:
On 09/30/15 14:41, Michael S. Tsirkin wrote:
> On Wed
On 09/30/2015 05:39 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote:
>>
>> On 09/30/2015 03:27 PM, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 03:16:04PM +0300, Vlad Zolotarov wrote:
>>>> On 09/30/15 15:03, Mi
On 09/30/2015 06:21 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 05:53:54PM +0300, Avi Kivity wrote:
>> On 09/30/2015 05:39 PM, Michael S. Tsirkin wrote:
>>> On Wed, Sep 30, 2015 at 04:05:40PM +0300, Avi Kivity wrote:
>>>> On 09/30/2015 03:27 PM, Michael
On 09/30/2015 11:40 PM, Michael S. Tsirkin wrote:
> On Wed, Sep 30, 2015 at 06:36:17PM +0300, Avi Kivity wrote:
>> As it happens, you're removing the functionality from the users who have no
>> other option. They can't use vfio because it doesn't work on virtualized
On 06/25/2015 06:18 PM, Matthew Hall wrote:
> On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia - HU/Budapest)
> wrote:
>> According to my understanding each packet should go
>> through BR as fast as possible, but it seems that the rte_eth_rx_burst
>> retrieves packets only when ther
On 06/25/2015 09:44 PM, Thomas Monjalon wrote:
> 2015-06-25 18:46, Avi Kivity:
>> On 06/25/2015 06:18 PM, Matthew Hall wrote:
>>> On Thu, Jun 25, 2015 at 09:14:53AM +, Vass, Sandor (Nokia -
>>> HU/Budapest) wrote:
>>>> According to my understanding e
66 matches
Mail list logo
