I get this error when running DPDK with the IGB driver in pktgen-dpdk
and other code:
PMD: WARNING: eth_igb_tx_queue_setup(): To improve 1G driver
performance, consider setting the TX WTHRESH value to 4, 8, or 16.
Internally, the code is checking "if (tx_conf->tx_thresh.wthresh == 0)".
But, I
Hello,
Since the pktgen code is reindented I am finding time to read through it
and experiment and see if I can get it working.
I have issues with the init process of pktgen. It is difficult to debug
it because the init code does a lot of very scary stuff to the terminal
control / TTY device
I should have mentioned. I suspect it must be missing some variations of
the PATCH subject line when it goes to pickup patches, as I am sending
them using git send-email but they still don't appear inside of
Patchwork. Or there is some way of deactivating or deleting which does
not send me any
Currently pktgen-dpdk and many other external apps will fail to compile
if the build output directory name is not equal to the target name.
This causes problems if you used an alternative build output directory.
Signed-off-by: Matthew Hall
---
mk/internal/rte.extvars.mk | 2 +-
1 file changed,
I have some outstanding minor patches which do not appear in Patchwork
anywhere I can see but the interface is also pretty confusing.
Is there a way to find all patches by a person throughout time so I can
see what happened to them and check why they are not listed and also not
merged (that I
SMP operations can be very expensive, sometimes can impact operations by 100s
to 1000s of clock cycles depending on what is the circumstances of the
synchronization. It is how you arrange the SMP operations within the tasks at
hand across the SMP cores that gives methods for top performance.
W dniu 18.01.2016 o 15:22, Yuanhan Liu pisze:
> On Wed, Dec 09, 2015 at 02:19:58PM +0100, Kamil Rytarowski wrote:
>> Currently rte_eal_check_module() detects Linux kernel modules via reading
>> /proc/modules. Built-in ones aren't listed there and therefore they are not
>> being found by the
W dniu 18.01.2016 o 15:32, Thomas Monjalon pisze:
> Hi Kamil,
>
> 2015-12-09 14:19, Kamil Rytarowski:
>> Currently dpdk_nic_bind.py detects Linux kernel modules via reading
>> /proc/modules. Built-in ones aren't listed there and therefore they are not
>> being found by the script.
>>
>> Add
Thank you, I will submit improved version as v6.
W dniu 18.01.2016 o 15:21, Yuanhan Liu pisze:
> Hi Kamil,
>
> First of all, sorry for no one has reviewed your patches for over one
> month! You may want to ping more often (say, per week) next time if it
> still happenes :)
>
> Another thing is
For non-x86 arch, Compiler will throw build error for in/out apis. Including
dummy api function so to pass build.
Note that: For virtio to work for non-x86 arch - RTE_EAL_VFIO is the only
supported method. RTE_EAL_IGB_UIO is not supported for non-x86 arch.
So, Virtio support for arch and
If virtio interface attached to vfio-noiommu driver then
do not parse for virtio resource. Instead exit with return 0;
Note: Applicable for virtio spec 0.95.
Signed-off-by: Santosh Shukla
---
v4-->v5:
- added _NOIOMMU drv check for lagecy virtio. No need for resource_init in vfio
case. And
Adding RTE_KDRV_VFIO_NOIOMMU mode in kernel driver. Also including
rte_vfio_is_noiommu() helper function. This function will parse
/sys/bus/pci/device// and make sure that
- vfio noiommu mode set in kernel driver
- pci device attached to vfio-noiommu driver only
If both condition satisfies then
So far virtio handle rw access for uio / ioport interface, This patch to extend
the support for vfio interface.
Applicable for virtio 0.95 spec.
Signed-off-by: Santosh Shukla
---
v4--> v5:
- Replaced virtio_rd/wr_1/2/4() macro implementation with inline function, per
Yuan review commment.
For vfio case - Use pread/pwrite api to access virtio
ioport space.
Applicable for virtio 0.95 spec.
Signed-off-by: Santosh Shukla
Signed-off-by: Rizwan Ansari
Signed-off-by: Rakesh Krishnamurthy
---
v4 --> v5:
- Removed unnecessary type casting.
drivers/net/virtio/virtio_vfio_rw.h | 104
Introducing below api for pci bar space rd/wr. Currently used for
pci iobar rd/wr.
Api's are:
- rte_eal_pci_read_bar
- rte_eal_pci_write_bar
virtio when used for vfio-mode then virtio driver will use these api
to do rd/wr operation on ioport pci bar.
Signed-off-by: Santosh Shukla
---
v4--> v5:
make sure sys/io.h used only for x86 archs. This fixes build error
arm64/arm case.
Signed-off-by: Santosh Shukla
---
drivers/net/virtio/virtio_pci.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/virtio/virtio_pci.h b/drivers/net/virtio/virtio_pci.h
index 99572a0..f550d22
vfio_pci_mmap() try to map all pci bars. ioport region are not mapped in
vfio/kernel so ignore mmaping for ioport.
Signed-off-by: Santosh Shukla
---
lib/librte_eal/linuxapp/eal/eal_pci_vfio.c | 20
1 file changed, 20 insertions(+)
diff --git
iopl() syscall not supported in linux-arm/arm64 so always return 0 value.
Signed-off-by: Santosh Shukla
Acked-by: Jan Viktorin
Suggested-by: Stephen Hemminger
---
lib/librte_eal/linuxapp/eal/eal.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/librte_eal/linuxapp/eal/eal.c
- virtio_recv_pkts_vec and other virtio vector friend apis are written for
sse/avx instructions. For arm64 in particular, virtio vector implementation
does not exist(todo).
So virtio pmd driver wont build for targets like i686, arm64. By making
RTE_VIRTIO_INC_VECTOR=n, Driver can build for
Hi,
Patch series uses vfio-noiommu-way to access virtio-net pci interface.
Tested for arm64 thunderX/ x86_64 platform. Patch builds for
x86/i386/arm/armv8/thunderX. Tested with testpmd application.
Patchset rebased on yuan's under review virtio-1.0 v2 patchset and using
vfio-noiommu patch. Refer
Dear all,
I am so sorry to send this question in dev mailing list. I sent this to
users' mailing list, but no one response and that list is not so active.
So, may I ask this question in this list? If it is not ok, I say sorry in
advance.
On 1/20/2016 12:25 AM, Tan, Jianfeng wrote:
> Hi Huawei,
>
> On 1/4/2016 10:46 PM, Huawei Xie wrote:
>> This patch removes the internal lockless enqueue implmentation.
>> DPDK doesn't support receiving/transmitting packets from/to the same
>> queue. Vhost PMD wraps vhost device as normal DPDK
virtio_pci.c is the only file references those macros; move them there.
Signed-off-by: Yuanhan Liu
Tested-by: Qian Xu
Reviewed-by: Tetsuya Mukawa
Tested-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_pci.c | 19 +++
drivers/net/virtio/virtio_pci.h | 18 --
2
Modern (v1.0) virtio pci device defines several pci capabilities.
Each cap has a configure structure corresponding to it, and the
cap.bar and cap.offset fields tell us where to find it.
Firstly, we map the pci resources by rte_eal_pci_map_device().
We then could easily locate a cfg structure by:
Normally we could set RTE_PCI_DRV_NEED_MAPPING flag so that eal will
invoke pci_map_device internally for us. From that point view, there
is no need to export pci_map_device.
However, for virtio pmd driver, which is designed to work without
binding UIO (or something similar first),
The mergeable virtio net hdr format has been the standard and the
only virtio net hdr format since virtio 1.0. Therefore, we can
not hardcode hdr_size to "sizeof(struct virtio_net_hdr)" any more
at virtio_recv_pkts(), otherwise, there would be a mismatch of
hdr size from rte_vhost_enqueue_burst()
Switch to 64 bit features, which virtio 1.0 supports.
While legacy virtio only supports 32 bit features, it complains aloud
and quit when trying to setting > 32 bit features.
Signed-off-by: Yuanhan Liu
Tested-by: Qian Xu
Reviewed-by: Tetsuya Mukawa
Tested-by: Tetsuya Mukawa
---
virtio_pci.c is a more proper place for pci stuff; virtio_ethdev is not.
Signed-off-by: Yuanhan Liu
Tested-by: Qian Xu
Reviewed-by: Tetsuya Mukawa
Tested-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_ethdev.c | 265 +---
drivers/net/virtio/virtio_pci.c|
Introduce struct virtio_pci_ops, to let legacy virtio (v0.95) and
modern virtio (1.0) have different implementation regarding to a
specific pci action, such as read host status.
With that, this patch reimplements all exported pci functions, in
a way like:
vtpci_foo_bar(struct virtio_hw
offset arg of vtpci_read/write_dev_config is derived from offsetof(),
which is of size_t type, instead of uint64_t. So, define it as size_t
type.
Signed-off-by: Yuanhan Liu
Tested-by: Qian Xu
Reviewed-by: Tetsuya Mukawa
Tested-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_pci.c | 4 ++--
As we have already set up it at virtio_dev_queue_setup(), and a vq
restart will not reset the settings.
Signed-off-by: Yuanhan Liu
Tested-by: Qian Xu
Reviewed-by: Tetsuya Mukawa
Tested-by: Tetsuya Mukawa
---
drivers/net/virtio/virtio_rxtx.c | 15 ---
1 file changed, 15
v5: minor fixes:
- fix wrong type of arg "offset" of read/write_dev_config(): patch 2
is newly added for that.
- check "offset + length" overflow
Almost all difference comes from virtio 1.0 are the PCI layout change:
the major configuration structures are stored at bar space, and
On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote:
> On Tue, 19 Jan 2016 09:29:31 -0500
> Neil Horman wrote:
>
> > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote:
> > > 2016-01-18 13:30, David Marchand:
> > > > We could do something ? la modinfo, but let's keep
On Tue, Jan 19, 2016 at 07:44:04AM +, Xie, Huawei wrote:
> On 1/19/2016 1:53 PM, Yuanhan Liu wrote:
> > On Mon, Jan 18, 2016 at 04:50:16PM +, Xie, Huawei wrote:
> >> On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> >>> -static void
> >>> +static int
> >>> virtio_negotiate_features(struct
max_rx_pkt_len already includes ETHER_HDR_LEN and ETHER_CRC_LEN for the
mtu. But, the firmware also adds ETHER_HDR_LEN and ETHER_CRC_LEN to the
mtu specified. Fix by subtracting these values from the mtu before
passing it to firmware.
Fixes: 4b2eff452d2e ("cxgbe: enable jumbo frames")
The size of each entry in the port's rss table is actually 2 bytes
and not 1 byte. A segfault occurs when accessing part of port 0's rss
table because it gets overwritten by subsequent port 1's part of the
rss table. Fix by setting the size of each entry appropriately.
Fixes: 92c8a63223e5
Patch 1 fixes a segfault due to an incorrect size allocated for
each entry in the rss table.
Patch 2 fixes an issue with setting wrong device mtu.
Rahul Lakkireddy (2):
cxgbe: fix segfault due to incorrect size allocated for rss table
cxgbe: fix setting wrong device mtu
On Mon, Jan 18, 2016 at 04:50:16PM +, Xie, Huawei wrote:
> On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> > -static void
> > +static int
> > virtio_negotiate_features(struct virtio_hw *hw)
> > {
> > uint64_t host_features;
> > @@ -949,6 +949,22 @@ virtio_negotiate_features(struct virtio_hw
On Tue, Jan 19, 2016 at 02:48:39AM +, Xie, Huawei wrote:
> On 1/19/2016 10:44 AM, Yuanhan Liu wrote:
> > On Tue, Jan 19, 2016 at 01:51:30AM +, Xie, Huawei wrote:
> >> On 1/19/2016 9:34 AM, Yuanhan Liu wrote:
> >>> On Mon, Jan 18, 2016 at 05:07:51PM +, Xie, Huawei wrote:
> .On
On Tue, 19 Jan 2016 15:56:14 -0500
Neil Horman wrote:
> On Tue, Jan 19, 2016 at 08:10:19AM -0800, Stephen Hemminger wrote:
> > On Tue, 19 Jan 2016 09:29:31 -0500
> > Neil Horman wrote:
> >
> > > On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote:
> > > > 2016-01-18 13:30, David
On 01/19/2016 11:59 AM, Ferruh Yigit wrote:
> On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote:
>> Ferruh Yigit writes:
>>> This work is to make DPDK ports more visible and to enable using common
>>> Linux tools to configure DPDK ports.
>>
>> This is a good goal. Only question - why
Jan,
On Tue, Jan 19, 2016 at 11:29 AM, Jan Viktorin
wrote:
> On Mon, 18 Jan 2016 22:11:56 +0100
> David Marchand wrote:
>> Ok, so what you propose is something like this ?
>
> I've expressed my basic understanding of this topic in the RFC patch set
> yesterday (as you know).
>
>>
>> - keep
On Mon, 18 Jan 2016 22:11:56 +0100
David Marchand wrote:
> Jan,
>
> I was waiting for some others feedbacks before going into the code.
> Glad to see you already tried this.
Of course... I think, it's better to have a particular code (if
possible) to talk about ;). It is quite difficult to see
Update the release note.
Also include the update for the last time of the ixgbe base
code update.
Signed-off-by: Wenzhuo Lu
---
doc/guides/rel_notes/release_2_3.rst | 54
1 file changed, 54 insertions(+)
diff --git a/doc/guides/rel_notes/release_2_3.rst
Add the support for new devices and mac types.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/ixgbe_bypass_api.h| 1 +
drivers/net/ixgbe/ixgbe_ethdev.c| 12 ++--
drivers/net/ixgbe/ixgbe_fdir.c | 10 +++---
drivers/net/ixgbe/ixgbe_pf.c
It's more valuable to abstract the interface. As such, change
the following method names:
read_i2c_combined => read_link
read_i2c_combined_unlocked => read_link_unlocked
write_i2c_combined => write_link
write_i2c_combined_unlocked => write_link_unlocked
The MDIO clock speed must be reconfigured after the MAC reset.
The MDIO clock speed becomes invalid, therefore the driver reads
invalid PHY register values. The driver now set the MDIO clock
speed prior to initializing PHY ops and again after the MAC reset.
As now the MDIO speed gets set in more
Do not set FDIRCTRL.DROP_NO_MATCH in ixgbe_init_fdir_perfect_82599(),
this bit is already set in ixgbe_set_fdir_drop_queue_82599() which
makes more sense for drivers that call that function.
This resolves an issue where packets were being dropped when switching
to perfect filters mode.
Setting
Only x550em_x V1 was supported before. Now V2 is supported.
A mask for V1 and V2 is defined and used to support both.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/ixgbe_type.h | 2 +-
drivers/net/ixgbe/base/ixgbe_x550.c | 19 +++
2 files changed, 12 insertions(+), 9
The X550EM_a device provides the MAC_SGMII_BUSY register to
indicate when slow SGMII register writes complete. Add
definitions for the register. No definitions are provided for
the individual bits under the theory that it is better to wait
for everything to complete when needed rather than try to
Instead of not defining the callback for set_phy_power when
manageability is enabled, put the check in the set_phy_power
function so that only turning the power off is conditional on
management, but not turning the PHY on.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/ixgbe_phy.c | 3
This patch resolves an issue where VF mac address is zeroed out
in cases where the VF driver is loaded while the PF interface
is down.
The solution is to only set it when we get an ACK from the PF.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/ixgbe_vf.c | 4 +++-
1 file changed, 3
Use the PHY token for PHY access on X550EM_a.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/ixgbe_x550.c | 114
drivers/net/ixgbe/base/ixgbe_x550.h | 2 +
2 files changed, 116 insertions(+)
diff --git a/drivers/net/ixgbe/base/ixgbe_x550.c
Add new X550EM_a devices and their mac types, X550EM_a
and X550EM_a_vf.
Update the code to use the new devices and mac types.
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/ixgbe_82599.c | 4 +-
drivers/net/ixgbe/base/ixgbe_api.c| 23 +
drivers/net/ixgbe/base/ixgbe_common.c
Signed-off-by: Wenzhuo Lu
---
drivers/net/ixgbe/base/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ixgbe/base/README b/drivers/net/ixgbe/base/README
index 5d66f86..caa2664 100644
--- a/drivers/net/ixgbe/base/README
+++ b/drivers/net/ixgbe/base/README
@@
*add new devices and mac type
*use PHY token for X550EM_a
*set VF mac address only when acked by PF
*always turn PHY power on when requested
*add definition of a register for mac SGMII busy
*support fuse for both x550em_x V1 and V2
*remove duplicate setting for fdir no match drop
*consolidate MDIO
On Tue, Jan 19, 2016 at 01:51:30AM +, Xie, Huawei wrote:
> On 1/19/2016 9:34 AM, Yuanhan Liu wrote:
> > On Mon, Jan 18, 2016 at 05:07:51PM +, Xie, Huawei wrote:
> >> .On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> >>> Modern (v1.0) virtio pci device defines several pci capabilities.
> >>>
On 2016/01/18 22:13, Tan, Jianfeng wrote:
> Hi Tetsuya,
>
> On 1/18/2016 5:13 PM, Tetsuya Mukawa wrote:
>> The patches abstract pci access method of virtio-net PMD.
>> The patch should be on Yuanhan's below patch series.
>> - [PATCH v4 0/8] virtio 1.0 enabling for virtio pmd driver
>>
>>
>>
On Sun, Jan 17, 2016 at 11:58 PM, Yuanhan Liu
wrote:
> On Sun, Jan 17, 2016 at 11:57:18AM -0800, Rich Lane wrote:
> > The common vhost code only supported a single mmap per device. vhost-user
> > worked around this by saving the address/length/fd of each mmap after
> the end
> > of the
On Mon, Jan 18, 2016 at 11:20:02AM -0500, Aaron Conole wrote:
> Ferruh Yigit writes:
> > This work is to make DPDK ports more visible and to enable using common
> > Linux tools to configure DPDK ports.
>
> This is a good goal. Only question - why use an additional kernel module
> to do this? Is
On Mon, Jan 18, 2016 at 05:07:51PM +, Xie, Huawei wrote:
> .On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> > Modern (v1.0) virtio pci device defines several pci capabilities.
> > Each cap has a configure structure corresponding to it, and the
> > cap.bar and cap.offset fields tell us where to
On Tue, Jan 19, 2016 at 08:30:40AM +0100, Thomas Monjalon wrote:
> 2016-01-18 13:30, David Marchand:
> > We could do something ? la modinfo, but let's keep it simple for now.
> >
> > With this, you can extract the devices that need to be bound to uio / vfio
> > with tools like objdump :
> >
> >
2016-01-08 12:03, Christian Ehrhardt:
> Depending on non-doc targets being built before and the setting of DESTDIR
> the copy of the examples dir being part of install-doc could in some cases
> fail
> with a non existant "$(DESTDIR)$(datadir)" target directory.
> Add the conditional rte_mkdir for
2016-01-18 13:30, David Marchand:
> We could do something ? la modinfo, but let's keep it simple for now.
>
> With this, you can extract the devices that need to be bound to uio / vfio
> with tools like objdump :
>
> $ objdump -j rte_pci_id_uio -s build/lib/librte_pmd_fm10k.so
>
> Contents of
On 1/19/2016 3:44 PM, Xie, Huawei wrote:
> On 1/19/2016 1:53 PM, Yuanhan Liu wrote:
>> On Mon, Jan 18, 2016 at 04:50:16PM +, Xie, Huawei wrote:
>>> On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
-static void
+static int
virtio_negotiate_features(struct virtio_hw *hw)
{
On 1/19/2016 1:53 PM, Yuanhan Liu wrote:
> On Mon, Jan 18, 2016 at 04:50:16PM +, Xie, Huawei wrote:
>> On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
>>> -static void
>>> +static int
>>> virtio_negotiate_features(struct virtio_hw *hw)
>>> {
>>> uint64_t host_features;
>>> @@ -949,6 +949,22 @@
On 1/19/2016 10:44 AM, Yuanhan Liu wrote:
> On Tue, Jan 19, 2016 at 01:51:30AM +, Xie, Huawei wrote:
>> On 1/19/2016 9:34 AM, Yuanhan Liu wrote:
>>> On Mon, Jan 18, 2016 at 05:07:51PM +, Xie, Huawei wrote:
.On 1/15/2016 12:34 PM, Yuanhan Liu wrote:
> Modern (v1.0) virtio pci
On 1/18/2016 9:44 PM, Yuanhan Liu wrote:
> On Mon, Jan 18, 2016 at 06:13:09PM +0900, Tetsuya Mukawa wrote:
>> +struct virtio_pci_access_ops {
>> +uint8_t (*legacy_read8)(struct virtio_hw *hw, uint8_t *addr);
>> +uint16_t (*legacy_read16)(struct virtio_hw *hw, uint16_t *addr);
>> +
> -Original Message-
> From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> Sent: Tuesday, January 19, 2016 4:06 AM
> To: Wang, Zhihong
> Cc: dev at dpdk.org; Ananyev, Konstantin ;
> Richardson, Bruce ; Xie, Huawei
>
> Subject: Re: [PATCH v2 0/5] Optimize memcpy for AVX512
Hi Julien
Nice of seeing your patch for this issue, which has been in our issue list.
I will ask a validation here for your patch. My comments inlined.
Thank you very much!
Regards,
Helin
-Original Message-
From: Julien Meunier [mailto:julien.meun...@6wind.com]
Sent: Tuesday, January
70 matches
Mail list logo
