Hi Maxime,
13.02.2020 16:54, Maxime Coquelin пишет:
> Hi Ivan,
>
> On 2/12/20 11:40 AM, Maxime Coquelin wrote:
>>
>> On 2/12/20 11:35 AM, Tiwei Bie wrote:
>>> On Fri, Feb 07, 2020 at 02:25:26PM +0300, Ivan Dyukov wrote:
Some applications like pktgen use link_speed to calculate
transmit r
On Mon, Aug 5, 2019 at 2:30 PM Thomas Monjalon wrote:
>
> The word "major" was used to differentiate with release candidates
> or stable maintenance releases.
> However the word "major" can be understood as "LTS",
> so it is less confusing to avoid this word.
>
> Reported-by: Ori Kam
> Signed-off
Hi,
Could I confirm that this patch is going to be merged in 20.02?
Regards,
Yasufumi
On 2019/12/06 19:44, Burakov, Anatoly wrote:
On 27-Nov-19 8:48 AM, Yasufumi Ogawa wrote:
From: Yasufumi Ogawa
In secondary_msl_create_walk(), it creates a file for fbarrays with its
PID for reserving uniqu
Some illegal packets will lead to TX hang. This patch checks those illegal
packets and protects TX from hanging.
Fixes: 7829b8d52be0 ("net/ixgbe: add Tx preparation")
Cc: sta...@dpdk.org
Signed-off-by: Xiao Zhang
---
drivers/net/ixgbe/ixgbe_rxtx.c | 6 ++
drivers/net/ixgbe/ixgbe_rxtx.h | 2
On Tue, Feb 11, 2020 at 2:08 PM Gaetan Rivet wrote:
>
> [...]
> >>> (gdb) p dev2
> >>> $5 = (struct rte_pci_device *) 0x54de5e0
> >>> (gdb) p /x *dev2
> >>> $6 = {next = {tqe_next = 0x5307460, tqe_prev = 0x5539f80}, device =
> >>> {next = {tqe_next = 0x0, tqe_prev = 0x0}, name = 0x54e4f00, driver
From: Pavan Nikhilesh
Each workslot is always bound to a specific lcore there is no multi-core
contention to cause cache trashing as a result it is safe to remove the
WFE. Also, in dual workslot dequeue work will mostlikely be available on
the pair workslot making WFE impractical.
Signed-off-by:
As per the comments in this code section, since there is a matching device,
it is now its responsibility to manage the devargs we've just inserted.
But the matching device ptr's devargs is still uninitialized or not pointing
to the newest dev_args that were passed as a parameter to local_dev_probe(
This patch extends creation of inline session to all the algorithms.
Previously the inline session was enabled only for AES-GCM cipher.
Fixes: 3a690d5a65e2 ("examples/ipsec-secgw: fix first packet with inline
crypto")
Signed-off-by: Ankur Dwivedi
---
examples/ipsec-secgw/sa.c | 26
Hi Erik/Robert,
I was looking at the rte_timer library code and have questions around
the way instances of timer list are allocated.
The API 'rte_timer_subsystem_init' allocates RTE_MAX_DATA_ELS (64) number of
timer data structs. Each timer data struct acts as an independent instance of
On 12/02/2020 10:05, Alex Williamson wrote:
> Given the mostly positive feedback from the RFC[1], here's a new
> non-RFC revision. Changes since RFC:
>
> - vfio_device_ops.match semantics refined
> - Use helpers for struct pci_dev.physfn to avoid breakage without
>CONFIG_PCI_IOV
> - Rel
Added support for API rte_eth_tx_done_cleanup.
Added support setting VF MAC address by PF driver.
Added support for setting the link to specific speed.
Signed-off-by: Jiaqi Min
---
doc/guides/rel_notes/release_20_02.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/guides/rel_not
Added support for API rte_eth_tx_done_cleanup.
Signed-off-by: Jiaqi Min
---
doc/guides/rel_notes/release_20_02.rst | 1 +
1 file changed, 1 insertion(+)
diff --git a/doc/guides/rel_notes/release_20_02.rst
b/doc/guides/rel_notes/release_20_02.rst
index 786f9b119..5d01dac58 100644
--- a/doc/guid
Added support for API rte_eth_tx_done_cleanup.
Added support for VF multiple queues interrupt.
Added support for setting the link to specific speed.
Signed-off-by: Jiaqi Min
---
doc/guides/rel_notes/release_20_02.rst | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/doc/gui
hi Xiao,
Thanks for your comments! I will fix them ASAP.
Best regards,
Xiaojun
From: Wang, Xiao W
Sent: Tuesday, February 11, 2020 6:31 PM
To: Xiaojun Liu
Cc: dev@dpdk.org ; Zhang, Qi Z ; Kwan,
Ngai-mint ; Fornal, Jakub ;
Keller, Jacob E ; Jeff Zheng
; Eyal C
On Thu, Feb 13, 2020 at 05:40:43PM +, Ray Kinsella wrote:
>
>
> On 05/02/2020 11:32, Neil Horman wrote:
> > On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote:
> >> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote:
> But if we can do the versioning in the master, LTS can b
> -Original Message-
> From: Ye, Xiaolong
> Sent: Thursday, February 13, 2020 2:46 PM
> To: Zhang, Xiao
> Cc: dev@dpdk.org; or...@mellanox.com; Zhang, Qi Z ;
> Su, Simei ; Iremonger, Bernard
>
> Subject: Re: [dpdk-dev] app/testpmd: parse flow command line for AH
>
> Hi, Xiao
>
> On
Add AH and AH SPI to testpmd rte flow command line.
Add note and sample AH rules in testpmd guide.
Signed-off-by: Xiao Zhang
---
v2 Add sample rules in testpmd guide.
---
app/test-pmd/cmdline_flow.c | 29 +
doc/guides/testpmd_app_ug/testpmd_funcs.rst |
On 2020-02-13 14:17, Thomas Monjalon wrote:
13/02/2020 21:58, dwilder:
On 2020-02-13 12:32, Thomas Monjalon wrote:
> 13/02/2020 21:24, David Wilder:
>> - The --no-huge option requires iova-mode=VA.
>> On ppc64le iova-mode defaults to PA therefor
>> VA mode must be explicitly set.
>
> Should
https://bugs.dpdk.org/show_bug.cgi?id=399
Bug ID: 399
Summary: ixgbe X540 PMD RSS is zero for NFSv3 NULL reply
Product: DPDK
Version: 18.11
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
13/02/2020 21:58, dwilder:
> On 2020-02-13 12:32, Thomas Monjalon wrote:
> > 13/02/2020 21:24, David Wilder:
> >> - The --no-huge option requires iova-mode=VA.
> >> On ppc64le iova-mode defaults to PA therefor
> >> VA mode must be explicitly set.
> >
> > Should we make VA mode automatic when u
On 2020-02-13 12:32, Thomas Monjalon wrote:
13/02/2020 21:24, David Wilder:
- The --no-huge option requires iova-mode=VA.
On ppc64le iova-mode defaults to PA therefor
VA mode must be explicitly set.
Should we make VA mode automatic when using --no-huge?
Should we log an error message when
On 05/08/2019 13:30, Thomas Monjalon wrote:
> The word "major" was used to differentiate with release candidates
> or stable maintenance releases.
> However the word "major" can be understood as "LTS",
> so it is less confusing to avoid this word.
>
> Reported-by: Ori Kam
> Signed-off-by: Thomas
13/02/2020 21:24, David Wilder:
> - The --no-huge option requires iova-mode=VA.
> On ppc64le iova-mode defaults to PA therefor
> VA mode must be explicitly set.
Should we make VA mode automatic when using --no-huge?
Should we log an error message when using --no-huge with PA mode?
This change follows the example of aarch64 Travis support
by adding support for ppc64le gcc builds. Limitations for
ppc64le are the same as aarch64 as described in commit
31bb45bcfd.
Signed-off-by: David Wilder
Reviewed-by: David Christensen
---
.travis.yml | 29 +
- Memory requirements are larger for ppc64le
due to a higher RTE_MAX_LCORE value.
- The --no-huge option requires iova-mode=VA.
On ppc64le iova-mode defaults to PA therefor
VA mode must be explicitly set.
Signed-off-by: David Wilder
Reviewed-by: David Christensen
---
devtools/test-null.s
This patch series adds Travis gcc compilation jobs for ppc64le.
Limitations for ppc64le are similar to arm64 (see commit
31bb45bcfd).
1. Only gcc builds are supported on ppc64le.
2. A container is used, therefor Huge pages are not available.
Unit tests are not run, a single test (test-null) us
13/02/2020 19:27, Ferruh Yigit:
> On 2/13/2020 3:52 PM, Thomas Monjalon wrote:
> > This fix is proposed as an alternative to
> > https://patches.dpdk.org/patch/65088/
> > The benefit is to fix a race condition in addition.
> >
> > Thomas Monjalon (2):
> > app/testpmd: rename function for detachi
On Sun, Feb 9, 2020 at 10:15 PM Thomas Monjalon wrote:
>
> Mellanox owns Tilera and EZchip, so the copyrights can be converted.
> At the same time, the license header is switched to SPDX tag format,
> and a typo is fixed in another copyright line.
>
> Signed-off-by: Thomas Monjalon
Applied, than
13/02/2020 17:05, Ferruh Yigit:
> On 2/13/2020 3:27 PM, Thomas Monjalon wrote:
> > 13/02/2020 16:16, Ferruh Yigit:
> >> On 2/13/2020 2:33 PM, Thomas Monjalon wrote:
> >>> The function rte_eth_dev_release_port() is called by drivers
> >>> when closing or removing a device.
> >>> Its main usage shoul
On 2/13/2020 1:57 AM, Wei Hu (Xavier) wrote:
> From: "Wei Hu (Xavier)"
>
> Currently, Rx offload capabilities and max_rx_pkt_len in the struct
> variable named rte_port are not updated after setting mtu successfully
> in port_mtu_set function by 'port config mtu ' command.
> This may lead to rec
On Thu, 13 Feb 2020 10:23:21 -0700
Alex Williamson wrote:
> On Thu, 13 Feb 2020 12:46:54 +0100
> Cornelia Huck wrote:
>
> > On Tue, 11 Feb 2020 16:05:42 -0700
> > Alex Williamson wrote:
> >
> > > If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
> > > fully isolated from
On 2/13/2020 3:52 PM, Thomas Monjalon wrote:
> This fix is proposed as an alternative to
> https://patches.dpdk.org/patch/65088/
> The benefit is to fix a race condition in addition.
>
> Thomas Monjalon (2):
> app/testpmd: rename function for detaching by devargs
> app/testpmd: fix hot-unplug
On 2/13/2020 2:50 PM, Thomas Monjalon wrote:
> User may try to run "port detach "
> for an already detached device.
> It has been decided to protect from such usage in testpmd,
> so a check was added to detach_port_device() in DPDK 19.11.
> This check might be removed to allow hotplug path detachin
On Thu, 13 Feb 2020 10:39:57 -0700
Alex Williamson wrote:
> On Thu, 13 Feb 2020 13:41:21 +0100
> Cornelia Huck wrote:
>
> > On Tue, 11 Feb 2020 16:05:51 -0700
> > Alex Williamson wrote:
> > > +struct vfio_device_feature {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > +#define VFIO_DEVIC
On 05/02/2020 11:32, Neil Horman wrote:
> On Wed, Feb 05, 2020 at 11:04:29AM +0100, Luca Boccassi wrote:
>> On Tue, 2020-02-04 at 07:02 -0500, Neil Horman wrote:
But if we can do the versioning in the master, LTS can backport it
and can have
mature version of that API in LTS witho
On Thu, 13 Feb 2020 13:41:21 +0100
Cornelia Huck wrote:
> On Tue, 11 Feb 2020 16:05:51 -0700
> Alex Williamson wrote:
>
> > The VFIO_DEVICE_FEATURE ioctl is meant to be a general purpose, device
> > agnostic ioctl for setting, retrieving, and probing device features.
> > This implementation pro
On Thu, Feb 6, 2020 at 12:54 PM wrote:
>
> From: Vamsi Attunuru
>
> SIGTERM handling is added for graceful application exit.
> Useful when application is terminated without specifying
> any signal on 'kill' command.
>
> Signed-off-by: Vamsi Attunuru
> Acked-by: Ferruh Yigit
Applied, thanks.
On Wed, Feb 12, 2020 at 6:14 PM Ferruh Yigit wrote:
>
> With the following Linux commit a new parameter 'txqueue' has been added
> to 'ndo_tx_timeout' ndo:
> commit 0290bd291cc0 ("netdev: pass the stuck queue to the timeout handler")
>
> The change reflected to the KNI with version check.
>
> Cc:
On Thu, 13 Feb 2020 12:46:54 +0100
Cornelia Huck wrote:
> On Tue, 11 Feb 2020 16:05:42 -0700
> Alex Williamson wrote:
>
> > If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
> > fully isolated from the PF. The PF can always cause a denial of
> > service to the VF, if not ac
On Thu, Feb 13, 2020 at 11:28:53AM +0100, Robin Jarry wrote:
> 2020-02-13, Kevin Traynor:
> > That is true for the distribution versions, but there may be developers
> > doing some compiling themselves using latest.
> >
> > I think it would be ok to start the process of removing python2 from
> > D
On 2/5/20 4:05 PM, Maxime Coquelin wrote:
> This patch adds a check to ensure the read size of
> the Vhost-user message header is not smaller than
> the expected size.
>
> In case of unexpected read size, report an error
> and close file descriptors passed with the message,
> if any.
>
> Fixes
On 12/25/19 3:18 PM, Jin Yu wrote:
> The frontend may not send the get_inflight_fd and
> set_inflight_fd although we negotiate the protocol
> feature. When we meet this situation just return OK.
>
> Fixes: ad0a4ae491fe ("vhost: checkout resubmit inflight information")
> Cc: sta...@dpdk.org
>
>
On 2/13/20 2:41 AM, Cheng Jiang wrote:
> Add release notes for the notification data feature of virtio-PMD.
>
> Signed-off-by: Cheng Jiang
> ---
> doc/guides/rel_notes/release_20_02.rst | 8
> 1 file changed, 8 insertions(+)
Applied to dpdk-next-virtio/master
Thanks,
Maxime
On 2/6/20 2:39 AM, Itsuro Oda wrote:
> vhost PMD has not been available for secondary processes since
> DPDK v18.11. (https://bugs.dpdk.org/show_bug.cgi?id=194)
> (for a long term !)
> This series of patches intend to make vhost PMD available for
> secondary processes.
> Because now setting vho
On 2/11/20 10:33 AM, Jin Yu wrote:
> Fix the time of check time of use warning in example code.
> Ignore the errno of unlink failure. There are two situations.
> The first one is that file doesn't exist the unlink fails and
> it's ok to ignore. The second one is that unlink fails to remove
> fil
On 2/13/20 5:18 PM, Maxime Coquelin wrote:
>
>
> On 2/13/20 11:04 AM, Adrian Moreno wrote:
>> Currently, the log address translation only happens in the vhost-user's
>> translate_ring_addresses(). However, the IOTLB update handler is not
>> checking if it was mapped to re-trigger that transla
On 2/13/20 11:04 AM, Adrian Moreno wrote:
> Currently, the log address translation only happens in the vhost-user's
> translate_ring_addresses(). However, the IOTLB update handler is not
> checking if it was mapped to re-trigger that translation.
>
> Since the log address mapping could fail, c
This adds new device id to the list of Mellanox devices
that runs mlx5 PMD.
- BlueField-2 integrated ConnectX-6 Dx network controller
This device is not ready yet, it is in development stage.
Signed-off-by: Raslan Darawsheh
---
doc/guides/rel_notes/release_20_02.rst | 1 +
drivers/common/mlx5/m
On 2/13/2020 3:27 PM, Thomas Monjalon wrote:
> 13/02/2020 16:16, Ferruh Yigit:
>> On 2/13/2020 2:33 PM, Thomas Monjalon wrote:
>>> The function rte_eth_dev_release_port() is called by drivers
>>> when closing or removing a device.
>>> Its main usage should be via rte_eth_dev_close() by up-to-date
>
There is a possible race condition in the hotplug path
in rmv_port_callback(). If a port is created between
close_port(port_id) and detach_port_device(port_id),
then the port_id will have been reallocated to a different
device which will be wrongly detached.
Since a check was added in detach_port_
There is a function detach_port_device() which takes a port_id,
and a function detach_device() which takes a devargs string.
In order to add a third function accepting a rte_device pointer,
the function detach_device() is renamed into detach_devargs().
Signed-off-by: Thomas Monjalon
---
app/test
This fix is proposed as an alternative to
https://patches.dpdk.org/patch/65088/
The benefit is to fix a race condition in addition.
Thomas Monjalon (2):
app/testpmd: rename function for detaching by devargs
app/testpmd: fix hot-unplug detaching
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/te
13/02/2020 16:16, Ferruh Yigit:
> On 2/13/2020 2:33 PM, Thomas Monjalon wrote:
> > The function rte_eth_dev_release_port() is called by drivers
> > when closing or removing a device.
> > Its main usage should be via rte_eth_dev_close() by up-to-date
> > drivers which are compliant with RTE_ETH_DEV_
On Tue, Feb 11, 2020 at 11:50 AM David Hunt wrote:
> When a VM sends a command through virtio-serial to enable/disable
> turbo, it is successfully enabled or disabled, yet the response to the
> VM is NACK. This is because all the library frequency change APIs return
> 1 for success (change in freq
On 2/13/2020 2:33 PM, Thomas Monjalon wrote:
> The function rte_eth_dev_release_port() is called by drivers
> when closing or removing a device.
> Its main usage should be via rte_eth_dev_close() by up-to-date
> drivers which are compliant with RTE_ETH_DEV_CLOSE_REMOVE flag.
>
> When a port is rel
On 2/13/2020 2:50 PM, Thomas Monjalon wrote:
> User may try to run "port detach "
> for an already detached device.
> It has been decided to protect from such usage in testpmd,
> so a check was added to detach_port_device() in DPDK 19.11.
> This check might be removed to allow hotplug path detachin
On Mon, Feb 10, 2020 at 8:05 AM Xiaoyun Li wrote:
>
> Added return value check for 'rte_eth_dev_info_get()'.
>
> Coverity issue: 349922
> Fixes: 2bb43bd4350a ("examples/tep_term: add TSO offload configuration")
rte_eth_dev_info_get() prototype changed in 19.11.
Before this, it was a void.
So this
Hi,
Two comments from me,
> > > The patch we're working on will provide two versions of
> > > rte_cryptodev_info_get(), both call the same PMD function from the
> dev_ops info_get fn ptr.
> > > The default version operates s as normal, the 19.11 version searches
> > > through the list returned by
User may try to run "port detach "
for an already detached device.
It has been decided to protect from such usage in testpmd,
so a check was added to detach_port_device() in DPDK 19.11.
This check might be removed to allow hotplug path detaching
the device of a closed port.
Whatever will be decided
The function rte_eth_dev_release_port() is called by drivers
when closing or removing a device.
Its main usage should be via rte_eth_dev_close() by up-to-date
drivers which are compliant with RTE_ETH_DEV_CLOSE_REMOVE flag.
When a port is released, the data (rte_eth_dev_data) are cleared,
but the p
On Fri, Feb 7, 2020 at 11:34 AM Ciara Power wrote:
>
> The return value of the get link function call was not checked, and
> could return a negative value indicating a failure. This meant the
> link_status of the link being checked is invalid, because the link was
> not filled with data. The retur
On Tue, Feb 4, 2020 at 5:10 PM Ciara Power wrote:
>
> The nb_dq return value from the ioat dequeue is negative in failure
> cases, however the variable was an unsigned int, causing the condition
> where nb_dq <= 0 to never be true. This is now cast to a signed int,
> which will successfully reflec
On Thu, Nov 28, 2019 at 12:32 PM Bruce Richardson
wrote:
>
> On Thu, Nov 28, 2019 at 11:27:14AM +, Praveen Shetty wrote:
> > patch checks the return value of function rte_eth_dev_info_get,
> > if return value is negative error message printed on the console.
> >
> > Coverity issue: 350361
> >
On 2/13/2020 1:36 PM, Thomas Monjalon wrote:
> More details below about the plan for 20.02.
>
> 13/02/2020 13:37, Thomas Monjalon:
>> Hi,
>>
>> This discussion becomes confusing so I do a summary below.
>> I think we can do several fixes in 20.02.
Thanks for checking this.
>>
>> 12/02/2020 14:49
On Mon, Dec 9, 2019 at 1:07 PM Bruce Richardson
wrote:
>
> On Mon, Dec 09, 2019 at 06:37:56AM +, Gargi Sau wrote:
> > This checks the return value from the function
> > rte_eth_dev_set_vlan_offload.
> >
> > Coverity issue: 350358
> > Fixes: bda68ab9d1e7 ("examples/ethtool: add user-space ethto
On Wed, Feb 12, 2020 at 2:48 PM Konstantin Ananyev
wrote:
>
> Fix problem with ACL library for 32-bit range fields,
> and extend UT to cover such cases in future.
>
> Konstantin Ananyev (2):
> acl: fix 32-bit range field doesn't work properly
> test/acl: add 32-bit range test-case
>
> app/tes
Hi,
> -Original Message-
> From: dev On Behalf Of Thomas Monjalon
> Sent: Thursday, February 13, 2020 12:07 AM
> To: dev@dpdk.org
> Cc: bruce.richard...@intel.com
> Subject: [dpdk-dev] [PATCH v5 0/6] mlx ibverbs linking in meson
>
> This is the follow-up of the feature I added one year a
Hi,
> -Original Message-
> From: dev On Behalf Of Matan Azrad
> Sent: Monday, February 10, 2020 2:28 PM
> To: dev@dpdk.org
> Cc: Slava Ovsiienko ; Thomas Monjalon
>
> Subject: [dpdk-dev] [PATCH] common/mlx5: fix dlopen meson build
>
> The glue shared library name was created by the comm
Hi Ivan,
On 2/12/20 11:40 AM, Maxime Coquelin wrote:
>
>
> On 2/12/20 11:35 AM, Tiwei Bie wrote:
>> On Fri, Feb 07, 2020 at 02:25:26PM +0300, Ivan Dyukov wrote:
>>> Some applications like pktgen use link_speed to calculate
>>> transmit rate. It limits outcome traffic to hardcoded 10G.
>>>
>>> Th
Hi.
The reason for changing these vectors is the same as for a bit similar Artur's
compression vectors change patch: http://patches.dpdk.org/patch/65616/
Basically speaking, we'd like to remove everything with unclear license. To do
that, I replaced all wireless crypto (SNOW3G, ZUC, KASUMI etc)
More details below about the plan for 20.02.
13/02/2020 13:37, Thomas Monjalon:
> Hi,
>
> This discussion becomes confusing so I do a summary below.
> I think we can do several fixes in 20.02.
>
> 12/02/2020 14:49, Ferruh Yigit:
> > On 2/3/2020 5:10 PM, Matan Azrad wrote:
>
> [stripping long di
The PMD manages internally the priority of the flows in addition to the
user configured priority.
So, 2 flows with the same user priority may get different priority.
The method:
As much as the flow is more specific it gets higher priority
(higher means first to be matched).
In addition, When the
aarch64 does not map pci resources to 'write-combine' nor
cacheable. In Linux Kernel arch_can_pci_mmap_wc() equals to 0 on
aarch64[1].
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
tree/drivers/pci/pci-sysfs.c?h=v5.4#n1204
Fixes: f078ceb6ae93 ("net/mlx5: fix Tx doorbell
From: Phil Yang
PMD Rx queue descriptor contains two mlx5_mprq_buf fields, which
are the multi-packet RQ buffer header pointers. It uses the common
rte_atomic_XXX functions to make sure the refcnt access is atomic.
The common rte_atomic_XXX functions are full barriers on aarch64.
Optimized it wi
To keep order of the modification of RX queue descriptor(rxq->cq_db) and
the CQ doorbell register, a rte_cio_wmb barrier is required.
The situation was rescued by the stronger than required barrier in the
mlx5_uar_write64, it becomes a must when the barrier is relaxed.
Fixes: 6bf10ab69be0 ("net/m
The barrier is not required or can be moved down if HW waits for the
doorbell ring to execute the WQE.
This is not the case as HW can start executing the WQE until it gets the
ownership(passed by SW writing the doorbell record).
Add a decriptive comment for this HW specific behavior.
Signed-off-
To ensure the WQE and doorbell record, which reside in the host memory,
are visible to HW before the blue frame, a CIO barrier is sufficient, a
rte_wmb is overkill.
Fixes: 6cb559d67b83 ("net/mlx5: add vectorized Rx/Tx burst for x86")
Cc: sta...@dpdk.org
Signed-off-by: Gavin Hu
Reviewed-by: Phil
The UAR is part of PCI address space that is mapped for direct access to
the HCA from the CPU. Read-Write accesses to this space are strongly
ordered thus a compiler barrier is sufficient for all arches.
This patch set is based on the following aarch64 architecural facts:
1. The PCI BAR space is m
Using just sufficient barriers really matters to performance.
Insufficient barriers will cause issues while barriers stronger
than required, especially in the fast path is a performance killer.
In the joint preliminary testing between Arm and Ampere, 8%~13%
performance was measured.
Gavin Hu (5):
On Tue, 11 Feb 2020 16:05:51 -0700
Alex Williamson wrote:
> The VFIO_DEVICE_FEATURE ioctl is meant to be a general purpose, device
> agnostic ioctl for setting, retrieving, and probing device features.
> This implementation provides a 16-bit field for specifying a feature
> index, where the data
Hi,
This discussion becomes confusing so I do a summary below.
I think we can do several fixes in 20.02.
12/02/2020 14:49, Ferruh Yigit:
> On 2/3/2020 5:10 PM, Matan Azrad wrote:
[stripping long discussion in favor of a summary below]
> > Even if the PMD clear the device pointer, the testpmd st
On 2/13/2020 8:49 AM, Ciara Loftus wrote:
> This series introduces some fixes for the zero copy path of the AF_XDP.
> In zero copy, the mempool objects are mapped directly into the AF_XDP UMEM.
> Below depicts the layout of an object in a mempool.
>
> +-++--+--+-+--
On Thu, Feb 13, 2020 at 1:07 PM Hemant Agrawal wrote:
> > I could not find a dependency in the makefiles for this.
> > But meson has this dependency.
> >
> > drivers/event/dpaa/meson.build
> > deps += ['pmd_dpaa', 'pmd_dpaa_sec']
> >
> >
> [Hemant] Makefile do have dependency set, but at a differe
On Tue, Feb 04, 2020 at 04:00:06PM +, Ciara Power wrote:
> The nb_dq return value from the ioat dequeue is negative in failure
> cases, however the variable was an unsigned int, causing the condition
> where nb_dq <= 0 to never be true. This is now cast to a signed int,
> which will successfull
On Fri, Feb 07, 2020 at 10:24:02AM +, Ciara Power wrote:
> The return value of the get link function call was not checked, and
> could return a negative value indicating a failure. This meant the
> link_status of the link being checked is invalid, because the link was
> not filled with data. Th
Hi David,
Sorry for taking time on it
> -Original Message-
> From: David Marchand
> Sent: Thursday, January 30, 2020 4:32 PM
> To: Hemant Agrawal
> Cc: Nipun Gupta ; dev
> Subject: Re: Dependency issue between event/dpaa and crypto/dpaa_sec
> Importance: High
>
> On Thu, Jan 30
On 07/02/2020 2:18 PM, Jerin Jacob wrote:
On Fri, Feb 7, 2020 at 6:08 PM Coyle, David wrote:
Hi Jerin, see below
Hi David,
On Thu, Feb 6, 2020 at 10:01 PM Coyle, David
wrote:
There is a risk in drafting API that meant for HW without any HW exists.
Because there could be inefficiency
On Tue, 11 Feb 2020 16:05:42 -0700
Alex Williamson wrote:
> If we enable SR-IOV on a vfio-pci owned PF, the resulting VFs are not
> fully isolated from the PF. The PF can always cause a denial of
> service to the VF, if not access data passed through the VF directly.
> This is why vfio-pci curre
On 06/02/2020 5:13 PM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 10:01 PM Coyle, David wrote:
Hi David,
- XGS-PON MAC: Crypto-CRC-BIP
- Order:
- Downstream: CRC, Encrypt, BIP
I understand if the chain has two operations then it may possible to
have handcrafted S
On 2/12/2020 5:27 PM, Lipiec, Herakliusz wrote:
>
>
>> -Original Message-
>> From: dev On Behalf Of Ferruh Yigit
>> Sent: Wednesday, February 12, 2020 2:00 PM
>> To: Burakov, Anatoly ; Govindharajan,
>> Hariprasad ; Lu, Wenzhuo
>> ; Wu, Jingjing ; Iremonger,
>> Bernard ; Mcnamara, John
>
On 06/02/2020 10:54 AM, Jerin Jacob wrote:
On Thu, Feb 6, 2020 at 3:35 PM Coyle, David wrote:
Hi Jerin,
Hi David,
Thanks for the comments. Please see replies below.
Kind Regards,
David
On Tue, Feb 4, 2020 at 8:15 PM David Coyle wrote:
Introduction
This RFC introduces a
On 2/13/2020 9:38 AM, Raslan Darawsheh wrote:
> Hi,
>
>> -Original Message-
>> From: Viacheslav Ovsiienko
>> Sent: Wednesday, February 12, 2020 7:49 PM
>> To: dev@dpdk.org
>> Cc: Matan Azrad ; Raslan Darawsheh
>> ; Ori Kam
>> Subject: [PATCH] net/mlx5: fix legacy non inline multi packet
On 2/13/20 12:09 PM, Kevin Traynor wrote:
> On 13/02/2020 10:04, Adrian Moreno wrote:
>> Currently, the log address translation only happens in the vhost-user's
>> translate_ring_addresses(). However, the IOTLB update handler is not
>> checking if it was mapped to re-trigger that translation.
>>
>
Minutes 13 February 2020
Agenda:
* Release Dates
* -rc2 status
* Subtrees
* OvS
Participants:
* Debian/Microsoft
* Intel
* Mellanox
* NXP
* Red Hat
Release Dates
-
* v20.02 dates:
* -rc2 is released on 6 February
* https://mails.dpdk.org/archives/dev/
> -Original Message-
> From: dev On Behalf Of Stephen Hemminger
> Sent: Wednesday, February 12, 2020 11:08 PM
> To: dev@dpdk.org
> Cc: Stephen Hemminger
> Subject: [dpdk-dev] [RFC 1/4] ring: future proof flag settings
>
> All API's should check that they support the flag values
> pass
On 13/02/2020 10:04, Adrian Moreno wrote:
> Currently, the log address translation only happens in the vhost-user's
> translate_ring_addresses(). However, the IOTLB update handler is not
> checking if it was mapped to re-trigger that translation.
>
> Since the log address mapping could fail, chec
On Tue, 11 Feb 2020 16:05:34 -0700
Alex Williamson wrote:
> This currently serves the same purpose as the default implementation
> but will be expanded for additional functionality.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/pci/vfio_pci.c |8
> 1 file changed, 8 inse
https://bugs.dpdk.org/show_bug.cgi?id=398
Bug ID: 398
Summary: MLX5 device won't start with no RX queue
Product: DPDK
Version: 19.11
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Pri
On Tue, 11 Feb 2020 16:05:25 -0700
Alex Williamson wrote:
> Allow bus drivers to provide their own callback to match a device to
> the user provided string.
>
> Signed-off-by: Alex Williamson
> ---
> drivers/vfio/vfio.c | 20
> include/linux/vfio.h |4
> 2 file
2020-02-13, Kevin Traynor:
> That is true for the distribution versions, but there may be developers
> doing some compiling themselves using latest.
>
> I think it would be ok to start the process of removing python2 from
> DPDK...but...there probably needs to be some deprecation notice and time
>
1 - 100 of 118 matches
Mail list logo
