2020-02-12, Bruce Richardson:
> I'm in favour of dropping the support in general, however, do we still not
> need to support some distro's e.g. Redhat/CentOS 7, which do not have
> python3?
Since the 7.7 release, python3 is now officially available in the
official repos:
https://access.redhat.com
> Subject: Re: [dpdk-dev] [PATCH v3 3/3] net/af_xdp: fix maximum MTU value
>
> On 02/10, Ciara Loftus wrote:
> >The maximum MTU for af_xdp zero copy is equal to the page size less the
> >frame overhead introduced by AF_XDP (XDP HR = 256) and DPDK (frame
> headroom
> >= 320). The patch updates this
The maximum MTU for af_xdp zero copy is equal to the page size less the
frame overhead introduced by AF_XDP (XDP HR = 256) and DPDK (frame headroom
= 320). The patch updates this value to reflect this.
This change also makes it possible to remove unneeded constants for both
zero-copy and copy mode
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.
+-++--+--+-+-+
| mp | struct | mbuf | mbuf | XDP |
The fill queue addresses should start at the beginning of the mempool
object instead of the beginning of the mbuf. This is because the umem
frame headroom includes the mp hdrobj size. Starting at this point
ensures AF_XDP doesn't write past the available room in the frame, in
the case of larger pac
The previous frame size calculation incorrectly used
mb_pool->private_data_size and didn't include mb_pool->header_size.
Instead of performing a manual calculation, use the
rte_mempool_calc_obj_size API to determine the frame size.
The previous frame headroom calculation also incorrectly used
mb_p
>
> >
> > This patch adds ability to run unit tests in cpu crypto mode for AESNI
> > GCM cryptodev.
> >
> > Signed-off-by: Marcin Smoczynski
> > ---
>
> Tested-by: Konstantin Ananyev
> Acked-by: Konstantin Ananyev
Acked-by: Akhil Goyal
On 13/02/2020 08:25, Robin Jarry wrote:
> 2020-02-12, Bruce Richardson:
>> I'm in favour of dropping the support in general, however, do we still not
>> need to support some distro's e.g. Redhat/CentOS 7, which do not have
>> python3?
>
> Since the 7.7 release, python3 is now officially available
On 02/13, Ciara Loftus wrote:
>The maximum MTU for af_xdp zero copy is equal to the page size less the
>frame overhead introduced by AF_XDP (XDP HR = 256) and DPDK (frame headroom
>= 320). The patch updates this value to reflect this.
>
>This change also makes it possible to remove unneeded constan
> >
> > This commit adds release notes and updates documentation for the cycle-
> > count mode added to the compression performance tool.
> >
> > Fixes: 2695db95a147 ("test/compress: add cycle-count mode to perf tool")
> >
> > Signed-off-by: Artur Trybula
>
> Acked-by: Adam Dybkowski
Applied t
> >
> > >
> > > This patch adds ability to run unit tests in cpu crypto mode for AESNI
> > > GCM cryptodev.
> > >
> > > Signed-off-by: Marcin Smoczynski
> > > ---
> >
> > Tested-by: Konstantin Ananyev
> > Acked-by: Konstantin Ananyev
> Acked-by: Akhil Goyal
Applied to dpdk-next-crypto
Thanks.
>
> >
> > Add missing BSD-3 license tag to inline fallback testing scripts.
> >
> > Signed-off-by: Marcin Smoczynski
> > ---
> > .../ipsec-secgw/test/trs_aesgcm_inline_crypto_fallback_defs.sh | 1 +
> > .../ipsec-secgw/test/tun_aesgcm_inline_crypto_fallback_defs.sh | 1 +
> > 2 files changed
> Hi Akhil,
>
> > Hi Artur,
> >
> > >
> > > 12/02/2020 14:25, Akhil Goyal:
> > > > Hi Thomas,
> > > >
> > > > >
> > > > > This patch replaces an existing test vector with a new one
> > > > > containing public domain text only. This is to avoid any potential
> > > > > issues re-licensing content
>
> When OpenSSL or AESNI-MB cryptodev is being used in sessionless mode
> for symmetric crypto operation (e.g. SHA256 hash), the driver prints
> error message:
>
> CRYPTODEV: set_sym_session_private_data() line 489:
>Set private data for driver 0 not allowed
>
> Then, AESNI-
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 session
>
> The commit being fixed introduced the differ
Acked-by: Hemant Agrawal
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, check it on iotlb updates.
Also, check it on vring_trans
Hi Jerin,
This patch (bug fix) is required for RC3.
Do you have any comments/concerns on this?
Thanks,
Nipun
> -Original Message-
> From: Hemant Agrawal
> Sent: Thursday, February 13, 2020 3:09 PM
> To: Nipun Gupta ; dev@dpdk.org
> Cc: Jerin Jacob Kollanukkaran ; sta...@dpdk.org;
> Nipu
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
>
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
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: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
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
> -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
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/
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.
>>
>
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 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/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 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 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 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
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 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
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 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 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.
>
> +-++--+--+-+--
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 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
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):
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
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-
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
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
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
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)
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,
> -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,
> -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
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
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 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 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 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 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
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
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
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
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
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 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 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
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_
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
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
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
>
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/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
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/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/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/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 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/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 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 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 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, 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 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 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 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 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 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 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 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
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 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 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
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
- 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 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 +
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?
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
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
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
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
1 - 100 of 118 matches
Mail list logo
