; Fixes: e1808999d36b ("vhost: restrict set max queue pair API to VDUSE")
> Cc: sta...@dpdk.org
>
> Signed-off-by: Maxime Coquelin
> ---
Thanks, Maxime! This makes the logs way less confusing.
Reviewed-by: Ilya Maximets
> lib/vhost/socket.c | 16 +---
>
erbosity
What do you think?
(Some wording may need changes obviously. For example, the doc says
the more critical levels are 'above' because they have 'higher importance',
but numbers are going the opposite direction. So words like 'reduce' or
'increase' are hard to interpret in this context.)
Best regards, Ilya Maximets.
On 9/26/23 11:17, David Marchand wrote:
> Hello Ilya,
>
> On Mon, Jul 31, 2023 at 10:40 PM Ilya Maximets wrote:
>> On 6/21/23 16:43, David Marchand wrote:
>>> As reported by Ilya [1], unconditionally calling
>>> rte_flow_get_restore_info() impacts an application
tion API, but it would
be nice if application could know it beforehand, i.e. had control
over when the flag is actually becomes visible.
Alternatively, the _register() could also be called right from
the rte_flow_restore_info_dynflag() at a slight performance cost.
It shouldn't be important though, since drivers do not seem to
call it from a performance-sensitive code.
Thoughts?
Best regards, Ilya Maximets.
On 10/26/22 17:34, Thomas Monjalon wrote:
> 13/10/2022 12:48, Ilya Maximets:
>> 'has_vlan' attribute is only supported by sfc, mlx5 and cnxk.
>> Other drivers doesn't support it. Most of them (like i40e) just
>> ignore it silently. Some drivers (like mlx4) ne
h at least two VLAN(the first TPID is 0x88A8
> and second TPID is 0x8100) and outer vid is 100 and the next vid is 200 can
> be matched.
>Is the above result correct ?
Seems correct, but I don't have much experience with rte_flow notations.
Ori, could you comment on this?
On 10/12/22 17:30, Thomas Monjalon wrote:
> 07/10/2022 13:55, Ilya Maximets:
>> On 10/7/22 13:50, Ilya Maximets wrote:
>>> On 9/12/22 12:09, Thomas Monjalon wrote:
>>>> 16/03/2022 13:01, Ilya Maximets:
>>>>> 'has_vlan' attribute is only suppo
'rte_flow_item_vlan', so changing
'vlan' to 'partial support' as well.
This doesn't solve the issue, but at least marks the problematic
drivers.
Some details are available in:
https://bugs.dpdk.org/show_bug.cgi?id=958
Fixes: 09315fc83861 ("ethdev: add VLA
On 10/7/22 13:50, Ilya Maximets wrote:
> On 9/12/22 12:09, Thomas Monjalon wrote:
>> 16/03/2022 13:01, Ilya Maximets:
>>> 'has_vlan' attribute is only supported by sfc, mlx5 and cnxk.
>>> Other drivers doesn't support it. Most of them (like i40e) just
&
On 9/12/22 12:09, Thomas Monjalon wrote:
> 16/03/2022 13:01, Ilya Maximets:
>> 'has_vlan' attribute is only supported by sfc, mlx5 and cnxk.
>> Other drivers doesn't support it. Most of them (like i40e) just
>> ignore it silently. Some drivers (like mlx4) ne
On 5/3/22 21:38, Van Haaren, Harry wrote:
>> -Original Message-
>> From: Ilya Maximets
>> Sent: Thursday, April 28, 2022 2:00 PM
>> To: Richardson, Bruce
>> Cc: i.maxim...@ovn.org; Mcnamara, John ; Hu, Jiayu
>> ; Maxime Coquelin ; Van
>> Haare
On 4/27/22 22:34, Bruce Richardson wrote:
> On Mon, Apr 25, 2022 at 11:46:01PM +0200, Ilya Maximets wrote:
>> On 4/20/22 18:41, Mcnamara, John wrote:
>>>> -Original Message-
>>>> From: Ilya Maximets
>>>> Sent: Friday, April 8, 2022 10:58 AM
&g
On 4/20/22 18:41, Mcnamara, John wrote:
>> -Original Message-
>> From: Ilya Maximets
>> Sent: Friday, April 8, 2022 10:58 AM
>> To: Hu, Jiayu ; Maxime Coquelin
>> ; Van Haaren, Harry
>> ; Morten Brørup ;
>> Richardson, Bruce
>> Cc
On 4/8/22 09:13, Hu, Jiayu wrote:
>
>
>> -Original Message-----
>> From: Ilya Maximets
>> Sent: Thursday, April 7, 2022 10:40 PM
>> To: Maxime Coquelin ; Van Haaren, Harry
>> ; Morten Brørup
>> ; Richardson, Bruce
>>
>> Cc: i.maxim
On 4/7/22 16:42, Van Haaren, Harry wrote:
>> -Original Message-
>> From: Ilya Maximets
>> Sent: Thursday, April 7, 2022 3:40 PM
>> To: Maxime Coquelin ; Van Haaren, Harry
>> ; Morten Brørup ;
>> Richardson, Bruce
>> Cc: i.maxim...@ovn.org;
sier
>> consumption and future development (as suggested in slides presented on last
>> call).
>>
>> Regards, -Harry
>>
>> No inline-replies below; message just for context.
>>
>>> -Original Message-----
>>> From: Van Haaren, Harry
>>
On 3/30/22 16:09, Bruce Richardson wrote:
> On Wed, Mar 30, 2022 at 01:41:34PM +0200, Ilya Maximets wrote:
>> On 3/30/22 13:12, Bruce Richardson wrote:
>>> On Wed, Mar 30, 2022 at 12:52:15PM +0200, Ilya Maximets wrote:
>>>> On 3/30/22 12:41, Ilya Maximets wrote:
>&
On 3/30/22 13:12, Bruce Richardson wrote:
> On Wed, Mar 30, 2022 at 12:52:15PM +0200, Ilya Maximets wrote:
>> On 3/30/22 12:41, Ilya Maximets wrote:
>>> Forking the thread to discuss a memory consistency/ordering model.
>>>
>>> AFAICT, dmadev can be anythin
On 3/30/22 12:41, Ilya Maximets wrote:
> Forking the thread to discuss a memory consistency/ordering model.
>
> AFAICT, dmadev can be anything from part of a CPU to a completely
> separate PCI device. However, I don't see any memory ordering being
> enforced or even describ
memory
barriers.
Would like to hear some thoughts on that topic. Is it a real issue?
Is it an issue considering all possible CPU architectures and DMA
HW variants?
Best regards, Ilya Maximets.
On 3/29/22 19:13, Morten Brørup wrote:
>> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
>> Sent: Tuesday, 29 March 2022 19.03
>>
>> On Tue, Mar 29, 2022 at 06:45:19PM +0200, Morten Brørup wrote:
From: Maxime Coquelin [mailto:maxime.coque...@redhat.com]
Sent: Tuesday, 29 March
On 3/21/22 19:23, Pai G, Sunil wrote:
> Hi all,
>
> Please see attached PDF which will be presented in the call.
Hi, Sunil.
Mail-list strips attachments. So, if you want to share the
presentation, upload it somewhere accessible and provide
a link instead.
Best regards, Ilya
On 3/16/22 10:41, Thomas Monjalon wrote:
> 15/03/2022 23:12, Ilya Maximets:
>> Hi, everyone.
>>
>> After implementing support for tunnel offloading in OVS we faced a
>> significant performance issue caused by the requirement to call
>> rte_flow_get_restore_info
.dpdk.org/show_bug.cgi?id=958
Fixes: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN items")
Cc: sta...@dpdk.org
Signed-off-by: Ilya Maximets
---
I added the stable in CC, but the patch should be extended while
backporting. For 21.11 the cnxk driver should be also updated,
nder the experimental API ifdef and not compiled-in
by default.
//Let me know if there is more formal way to submit such requests.
Best regards, Ilya Maximets.
uch for OVS.
One thing to highlight though: Change of main release schema
seems to directly impact schedule of stable releases.
In this case, interval between DPDK stable releases increases
from 3+ to 4+ months. This might be a long time to wait for
certain bug fixes, especially if OVS needs to skip one of the
DPDK stable releases due to issues introduced in it.
Anyway, doesn't sound like something critical to me.
Bets regards, Ilya Maximets.
On 8/24/21 6:04 PM, Eli Britstein wrote:
>
> On 8/24/2021 6:47 PM, Ilya Maximets wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 8/24/21 5:25 PM, Eli Britstein wrote:
>>> On 8/24/2021 6:08 PM, Finn, Emma wrote:
>>&g
On 8/24/21 5:25 PM, Eli Britstein wrote:
>
> On 8/24/2021 6:08 PM, Finn, Emma wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> -Original Message-
>> From: Eli Britstein
>> Sent: Monday 16 August 2021 14:55
>> To:
If the definition of a DPDK API allows interpretations that doesn't match with
the implementation inside the DPDK itself, that's not a fault of the external
application. And this can not be labeled as "misuse"/"misread". Let's not
create a precedent.
Best regards, Ilya Maximets.
On 6/3/21 1:29 PM, Ivan Malov wrote:
> On 03/06/2021 12:29, Ilya Maximets wrote:
>> On 6/2/21 9:35 PM, Ivan Malov wrote:
>>> On 02/06/2021 20:35, Ilya Maximets wrote:
>>>> (Dropped Broadcom folks from CC. Mail server refuses to accept their
>>>> emails fo
On 6/7/21 2:08 PM, Ori Kam wrote:
>
>
>> -Original Message-
>> From: Andrew Rybchenko
>> semantics
>>
>> On 6/7/21 11:28 AM, Thomas Monjalon wrote:
>>> 03/06/2021 11:55, Andrew Rybchenko:
On 6/3/21 12:18 PM, Ori Kam wrote:
> Sorry but OVS got it right, this is the idea to send p
On 6/3/21 12:33 PM, Andrew Rybchenko wrote:
> On 6/3/21 12:29 PM, Ilya Maximets wrote:
>> On 6/2/21 9:35 PM, Ivan Malov wrote:
>>> On 02/06/2021 20:35, Ilya Maximets wrote:
>>>> (Dropped Broadcom folks from CC. Mail server refuses to accept their
>>>>
On 6/2/21 9:35 PM, Ivan Malov wrote:
> On 02/06/2021 20:35, Ilya Maximets wrote:
>> (Dropped Broadcom folks from CC. Mail server refuses to accept their
>> emails for some reason: "Recipient address rejected: Domain not found."
>> Please, try to ad them back on
(Dropped Broadcom folks from CC. Mail server refuses to accept their
emails for some reason: "Recipient address rejected: Domain not found."
Please, try to ad them back on reply.)
On 6/2/21 6:26 PM, Andrew Rybchenko wrote:
> On 6/2/21 3:46 PM, Ilya Maximets wrote:
>> On 6
On 6/2/21 2:16 PM, Thomas Monjalon wrote:
> 01/06/2021 14:10, Ilya Maximets:
>> On 6/1/21 1:14 PM, Ivan Malov wrote:
>>> By its very name, action PORT_ID means that packets hit an ethdev with the
>>> given DPDK port ID. At least the current comments don't state th
an
upstream port or the representor and demystify the internals of the switchdev
NIC, there should be a different port id for the representor itself that
could be used in all DPDK APIs including rte_flow API or a special bit for
that matter. IIRC, there was an idea to add a bit directly to the port_
l and also matches with how the average user thinks about
representor devices.
If some specific use-case requires to distinguish VF from the representor,
there should probably be a separate special API/flag for that.
Best regards, Ilya Maximets.
On 3/25/21 5:43 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 25, 2021 at 12:00:11PM +0100, Ilya Maximets wrote:
>> On 3/25/21 10:35 AM, Stefan Hajnoczi wrote:
>>> On Wed, Mar 24, 2021 at 02:11:31PM +0100, Ilya Maximets wrote:
>>>> On 3/24/21 1:05 PM, Stefan Hajnoczi wro
On 3/25/21 10:35 AM, Stefan Hajnoczi wrote:
> On Wed, Mar 24, 2021 at 02:11:31PM +0100, Ilya Maximets wrote:
>> On 3/24/21 1:05 PM, Stefan Hajnoczi wrote:
>>> On Tue, Mar 23, 2021 at 04:54:57PM -0400, Billy McFall wrote:
>>>> On Tue, Mar 23, 2021 at 3:52 PM Ilya Maxim
On 3/24/21 10:51 PM, Maxime Coquelin wrote:
>
>
> On 3/24/21 10:39 PM, Ilya Maximets wrote:
>> On 3/24/21 9:56 PM, Maxime Coquelin wrote:
>>> Hi Ilya,
>>>
>>> On 3/19/21 5:45 PM, Ilya Maximets wrote:
>>>> On 3/19/21 5:11 PM, Ilya Maximets
On 3/24/21 9:56 PM, Maxime Coquelin wrote:
> Hi Ilya,
>
> On 3/19/21 5:45 PM, Ilya Maximets wrote:
>> On 3/19/21 5:11 PM, Ilya Maximets wrote:
>>> On 3/19/21 3:39 PM, Stefan Hajnoczi wrote:
>>>> Hi Ilya,
>>>> By the way, it's not clear
On 3/24/21 1:05 PM, Stefan Hajnoczi wrote:
> On Tue, Mar 23, 2021 at 04:54:57PM -0400, Billy McFall wrote:
>> On Tue, Mar 23, 2021 at 3:52 PM Ilya Maximets wrote:
>>
>>> On 3/23/21 6:57 PM, Adrian Moreno wrote:
>>>>
>>>>
>>>> On 3/19/2
> On Mon, Mar 22, 2021 at 10:49:54AM +0100, Christian Ehrhardt wrote:
>>>>>> On Thu, Mar 18, 2021 at 7:25 PM Pai G, Sunil
>>>>>> wrote:
>>>>>>> Hi Christian, Ilya
>>>>>>> From: Ilya Maximets
>>>>>>>>
On 3/23/21 6:57 PM, Adrian Moreno wrote:
>
>
> On 3/19/21 6:21 PM, Stefan Hajnoczi wrote:
>> On Fri, Mar 19, 2021 at 04:29:21PM +0100, Ilya Maximets wrote:
>>> On 3/19/21 3:05 PM, Stefan Hajnoczi wrote:
>>>> On Thu, Mar 18, 2021 at 08:47:12PM +0100, Ilya Maxi
On 3/19/21 5:11 PM, Ilya Maximets wrote:
> On 3/19/21 3:39 PM, Stefan Hajnoczi wrote:
>> Hi Ilya,
>> By the way, it's not clear to me why dpdkvhostuser is deprecated. If OVS
>> is restarted then existing vhost-user connections drop with an error but
>> QEMU could
t;.
BTW, virtio-user ports in DPDK doesn't support re-connection in client
mode too.
BTW2, with SocketPair Broker it might be cheaper to implement server
reconnection in QEMU because all connections in these case are client
connections, i.e. both ends will connect() to a broker.
Bets regards, Ilya Maximets.
On 3/19/21 3:16 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 18, 2021 at 09:14:27PM +0100, Ilya Maximets wrote:
>> On 3/18/21 8:47 PM, Ilya Maximets wrote:
>>> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
>>>> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
On 3/19/21 3:05 PM, Stefan Hajnoczi wrote:
> On Thu, Mar 18, 2021 at 08:47:12PM +0100, Ilya Maximets wrote:
>> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
>>> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
>>>> And some housekeeping usually require
On 3/19/21 9:51 AM, Marc-André Lureau wrote:
> Hi
>
> On Thu, Mar 18, 2021 at 11:47 PM Ilya Maximets <mailto:i.maxim...@ovn.org>> wrote:
>
> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
> > On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
>
On 3/18/21 8:47 PM, Ilya Maximets wrote:
> On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
>> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
>> Hi,
>> Some questions to understand the problems that SocketPair Broker solves:
>>
>>> Even more confi
On 3/18/21 6:52 PM, Stefan Hajnoczi wrote:
> On Wed, Mar 17, 2021 at 09:25:26PM +0100, Ilya Maximets wrote:
> Hi,
> Some questions to understand the problems that SocketPair Broker solves:
>
>> Even more configuration tricks required in order to share some sockets
>> betw
On 3/18/21 2:36 PM, Pai G, Sunil wrote:
> Hey Christian,
>
>
>
>> back in 19.11.4 these DPDK changes were not picked up as they have broken
>> builds as discussed here.
>> Later on the communication was that all this works fine now and thereby
>> Luca has "reverted the reverts" in 19.11.6 [1].
, this infrastructure might be
used later to implement client reconnection for virtio-user.
Signed-off-by: Ilya Maximets
---
doc/guides/nics/virtio.rst| 5 +
drivers/net/virtio/meson.build| 6 +
drivers/net/virtio/virtio_user/vhost_user.c | 118 +++
me to avoid big code refactoring. And vhost library
already expects the socket path in this format.
Ex.:
--vdev="eth_vhost0,iface=./one.socket,broker-key=mykey,client=1"
Signed-off-by: Ilya Maximets
---
doc/guides/nics/vhost.rst | 5
drivers/
ause vhost library treats
socket path as a unique device identifier.
'' is a broker key that will be used by a broker to identify
two clients that needs to be paired together, i.e. vhost device
will be connected with a client that provided the same key.
libspbroker needed for a build.
upport server mode")
Cc: sta...@dpdk.org
Signed-off-by: Ilya Maximets
---
CC: Zhiyong Yang
drivers/net/virtio/virtio_user/vhost_user.c | 4 +-
.../net/virtio/virtio_user/virtio_user_dev.c | 70 ++-
.../net/virtio/virtio_user/virtio_user_dev.h | 2 +-
3 files changed, 57 ins
de of this series. It basically fixes unregistering of a
listening socket that never happens in current code.
The virtio-user part of the series heavily depends on this bug fix
since broker connection unlike listening socket will not persist and
will generate lots of interrupts if not unregistere
o apt update || true
> - name: Install packages
> run: sudo apt install -y ccache libnuma-dev python3-setuptools
> python3-wheel python3-pip python3-pyelftools ninja-build libbsd-dev
>
LGTM,
Acked-by: Ilya Maximets
On 2/1/21 2:16 PM, Maxime Coquelin wrote:
> Hi Ilya,
>
> On 2/1/21 2:03 PM, Ilya Maximets wrote:
>> CC: ovs-dev
>>
>> On 2/1/21 2:00 PM, Ilya Maximets wrote:
>>> On 1/26/21 11:15 AM, Maxime Coquelin wrote:
>>>>
>>>> Only functionnal cha
CC: ovs-dev
On 2/1/21 2:00 PM, Ilya Maximets wrote:
> On 1/26/21 11:15 AM, Maxime Coquelin wrote:
>>
>> Only functionnal change in this second part is making the
>> Vhost-user server mode blocking at init time, as long as
>> a client is not connected. The goal of th
#x27;s
deprecated for a long time now, but I think it might still be in
use by some people, especially for virtio-user usecase.
Best regards, Ilya Maximets.
ort rdseed.
>> and that cause a dpdk bug. To workaround, you change: Not tested, hope
>> it's useful for you
>>
>>
> You are correct CPU doesn't support RDSEED instruction but RDRAND is
> supported.
>
> It's a RT kernel based on 4.19 + RT patches.
&g
On 14.11.2019 4:45, Cui, LunyuanX wrote:
> Hi, Ilya Maximets
>
> Before my patch, original treatment is as follows:
> esdp_reg = IXGBE_READ_REG(hw, IXGBE_ESDP);
> if ((esdp_reg & IXGBE_ESDP_SDP3))
> link_up = 0;
>
> if (link_u
pdate() is triggered and current link status is
down. When cable is plugged-in, link setup will be performed via
ixgbe_setup_link().
Signed-off-by: Laurent Hardy
Acked-by: Wei Dai
Does it fixed?
If not, you should not touch the alarm handler or implement a different
workaro
On 04.11.2019 21:33, Shahaf Shuler wrote:
Monday, November 4, 2019 12:28 PM, Ilya Maximets:
Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from
host
On 03.11.2019 7:48, Shahaf Shuler wrote:
Friday, November 1, 2019 11:33 AM, Ilya Maximets:
Subject: Re: [dpdk-dev] [PATCH
On 04.11.2019 15:30, Asaf Penso wrote:
Regards,
Asaf Penso
-Original Message-
From: dev On Behalf Of Ilya Maximets
Sent: Monday, November 4, 2019 12:28 PM
To: Shahaf Shuler ; Ilya Maximets
; Thomas Monjalon
Cc: dev@dpdk.org; Jerin Jacob ; Andrew
Rybchenko ; Ferruh Yigit
; Stephen
On 03.11.2019 7:48, Shahaf Shuler wrote:
Friday, November 1, 2019 11:33 AM, Ilya Maximets:
Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from
host
On 30.10.2019 22:42, Thomas Monjalon wrote:
30/10/2019 17:09, Ilya Maximets:
On 30.10.2019 16:49, Thomas Monjalon wrote:
30
On 01.11.2019 10:06, Ilya Maximets wrote:
On 01.11.2019 1:24, Thomas Monjalon wrote:
30/10/2019 10:24, Jerin Jacob:
On Wed, Oct 30, 2019 at 12:52 PM Shahaf Shuler wrote:
Wednesday, October 30, 2019 6:09 AM, Jerin Jacob:
Subject: Re: [dpdk-dev] [PATCH v2 0/3] ethdev: configure SR-IOV VF from
On 30.10.2019 22:42, Thomas Monjalon wrote:
30/10/2019 17:09, Ilya Maximets:
On 30.10.2019 16:49, Thomas Monjalon wrote:
30/10/2019 16:07, Ilya Maximets:
On 29.10.2019 19:50, Thomas Monjalon wrote:
In a virtual environment, the network controller may have to configure
some SR-IOV VF
7;t
find a way to enable VFs on Intel NICs if PF is under control of vfio-pci.
Best regards, Ilya Maximets.
On 30.10.2019 16:49, Thomas Monjalon wrote:
30/10/2019 16:07, Ilya Maximets:
On 29.10.2019 19:50, Thomas Monjalon wrote:
In a virtual environment, the network controller may have to configure
some SR-IOV VF parameters for security reasons.
When the PF (host port) is driven by DPDK (OVS-DPDK
On 29.10.2019 19:50, Thomas Monjalon wrote:
In a virtual environment, the network controller may have to configure
some SR-IOV VF parameters for security reasons.
When the PF (host port) is driven by DPDK (OVS-DPDK case),
we face two different cases:
- driver is bifurcated (Mellanox case),
sable segmentation offloading from the host side to avoid
having such a big buffers.
Cc: Flavio Leitner
Fixes: 5005bcda7123 ("vhost: add support for large buffers")
Signed-off-by: Ilya Maximets
---
There is still an assumption that users are sane enough to have
MTU sized mbufs in a memor
Hi.
Not a full review. Few comments inline.
Best regards, Ilya Maximets.
On 15.10.2019 18:17, Flavio Leitner wrote:
The rte_vhost_dequeue_burst supports two ways of dequeuing data.
If the data fits into a buffer, then all data is copied and a
single linear buffer is returned. Otherwise it
catching
mempool issues and needs to be returned back.
Cc: Flavio Leitner
Fixes: 5005bcda7123 ("vhost: add support for large buffers")
Signed-off-by: Ilya Maximets
---
lib/librte_vhost/virtio_net.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/lib/li
On 16.10.2019 16:02, Flavio Leitner wrote:
On Wed, 16 Oct 2019 15:46:15 +0200
Maxime Coquelin wrote:
On 10/16/19 3:32 PM, Ilya Maximets wrote:
On 16.10.2019 13:13, Maxime Coquelin wrote:
On 10/15/19 8:59 PM, Flavio Leitner wrote:
The rte_vhost_dequeue_burst supports two ways of dequeuing
On 16.10.2019 15:46, Maxime Coquelin wrote:
On 10/16/19 3:32 PM, Ilya Maximets wrote:
On 16.10.2019 13:13, Maxime Coquelin wrote:
On 10/15/19 8:59 PM, Flavio Leitner wrote:
The rte_vhost_dequeue_burst supports two ways of dequeuing data.
If the data fits into a buffer, then all data is
d send a separate patch for this if needed.
Best regards, Ilya Maximets.
ol_flags), but
we'll have to do it anyway for upgrade to DPDK 19.11.
Best regards, Ilya Maximets.
The current patch pushes the decision to the application which
knows better the workload. If more memory is available, it can
optionally use large buffers, otherwise just don't pass that.
ly small constant, loops should be
unrolled by compiler producing almost same code.
This will significantly reduce code size and will also allow to
play with PACKED_DESCS_BURST value without massive code changes.
Same is applicable to other patches in the series.
What do you think?
Best reg
On 08.07.2019 20:13, Marvin Liu wrote:
> In fast enqueue function, will first check whether descriptors are
> cache aligned. Fast enqueue function will check prerequisites in the
> beginning. Fast enqueue function do not support chained mbufs, normal
> function will handle that.
>
> Signed-off-by:
On 19.06.2019 18:14, Nikos Dragazis wrote:
> Hi everyone,
Hi. I didn't look at the code, just a few comments inline.
>
> this patch series introduces the concept of the virtio-vhost-user
> transport. This is actually a revised version of an earlier RFC
> implementation that has been proposed by
On 06.06.2019 13:02, Ilya Maximets wrote:
> According to API, 'rte_dev_probe()' and 'rte_dev_remove()' must
> return 0 or negative error code. Bus code returns positive values
> if device wasn't recognized by any driver, so the result of
> 'bus->plug/
If (or when) OVS Travis will migrate to meson, I'd suggest to just
use '-Denable_kmods=false'.
Best regards, Ilya Maximets.
od example by respecting
DPDK API. This also will allow to catch such issues in the future.
CC: sta...@dpdk.org
Fixes: a3ee360f4440 ("eal: add hotplug add/remove device")
Fixes: 244d5130719c ("eal: enable hotplug on multi-process")
Signed-off-by: Ilya Maximets
---
Version 2:
On 03.06.2019 19:13, David Marchand wrote:
>
>
> On Mon, Jun 3, 2019 at 5:37 PM Ilya Maximets <mailto:i.maxim...@samsung.com>> wrote:
>
> On 03.06.2019 11:50, David Marchand wrote:
> >
> >
> > On Thu, May 30, 2019 at 3:26 PM Ily
On 03.06.2019 11:50, David Marchand wrote:
>
>
> On Thu, May 30, 2019 at 3:26 PM Ilya Maximets <mailto:i.maxim...@samsung.com>> wrote:
>
> According to API, 'rte_dev_probe()' and 'rte_dev_remove()' and their
> 'hotplug' e
ust be converted.
Positive on remove means that device not found by driver.
Positive on probe means that there are no suitable buses/drivers,
i.e. device is not supported.
CC: sta...@dpdk.org
Fixes: a3ee360f4440 ("eal: add hotplug add/remove device")
Fixes: 244d5130719c ("eal: enable hot
Don't need to check dependencies if test apps will not be built anyway.
Signed-off-by: Ilya Maximets
---
Version 2:
- 'get_option('tests')' check moved to the top.
app/test/meson.build | 141 ++-
1 file changed, 72 insertions(
On 30.05.2019 14:55, Bruce Richardson wrote:
> On Wed, May 29, 2019 at 07:39:57PM +0300, Ilya Maximets wrote:
>> Don't need to check dependencies if test apps will not be built anyway.
>>
>> Signed-off-by: Ilya Maximets
>> -
On 30.05.2019 14:06, Luca Boccassi wrote:
> On Thu, 2019-05-30 at 13:03 +0300, Ilya Maximets wrote:
>> On 29.05.2019 23:37, Luca Boccassi wrote:
>>> On Wed, 2019-05-29 at 19:39 +0300, Ilya Maximets wrote:
>>>> The first thing many developers do before start building
On 30.05.2019 13:22, Bruce Richardson wrote:
> On Wed, May 29, 2019 at 09:37:20PM +0100, Luca Boccassi wrote:
>> On Wed, 2019-05-29 at 19:39 +0300, Ilya Maximets wrote:
>>> The first thing many developers do before start building DPDK is
>>> disabling all the not needed
On 29.05.2019 23:37, Luca Boccassi wrote:
> On Wed, 2019-05-29 at 19:39 +0300, Ilya Maximets wrote:
>> The first thing many developers do before start building DPDK is
>> disabling all the not needed divers and libraries. This happens
>> just because more than a half of DPDK
On 29.05.2019 23:15, Michael Santana Francisco wrote:
> On 5/29/19 12:39 PM, Ilya Maximets wrote:
>> The first thing many developers do before start building DPDK is
>> disabling all the not needed divers and libraries. This happens
>> just because more than a half of DPDK
rrect set of libraries to satisfy
all dependencies. However, it's not a big deal. Options intended
for a proficient users who knows what they need.
Signed-off-by: Ilya Maximets
---
app/meson.build | 5 +
drivers/baseband/meson.build | 5 +
drivers/bus/meson.bu
Don't need to check dependencies if test apps will not be built anyway.
Signed-off-by: Ilya Maximets
---
app/test/meson.build | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/app/test/meson.build b/app/test/meson.build
index 8339
See the full description in patch #2.
Please, let me know if I'm missing some obvious way to disable
libs and drivers in meson.
Ilya Maximets (2):
meson: don't check dependencies for tests if not required
meson: make build configurable
app/meson.build | 5 +
all vrings disabled by default and only process 'vring_state_changed'
events.
Fixes: 321203a54ba7 ("vhost: enable rings at the right time")
Cc: sta...@dpdk.org
Signed-off-by: Ilya Maximets
---
lib/librte_vhost/vhost_user.c | 6 +-
1 file changed, 5 insertions(+), 1 delet
cks for socket open/close")
Cc: sta...@dpdk.org
Signed-off-by: Ilya Maximets
---
Version 2:
* Fixed wrong order of 'destroy_device' and 'destroy_connection'.
lib/librte_vhost/socket.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/
On 12.04.2019 7:39, Tiwei Bie wrote:
> On Tue, Apr 09, 2019 at 04:36:22PM +0300, Ilya Maximets wrote:
>> Application should be able to obtain information like 'ifname' from
>> the 'vid' passed to 'destroy_connection' callback. Currently, all the
>
1 - 100 of 430 matches
Mail list logo
