[dpdk-dev] i40e: Steps and required configurations of how to achieve the best performance!

Zhang, Helin helin.zhang at intel.com
Fri Sep 19 05:43:12 CEST 2014


Hi David

I agree with you that we need to re-think of these two configurations. Thank you very much for the good comments!

My idea on it could be,

1.       Write a script to use ‘setpci’ to configure pci configuration. End user can decide which PCI device needs to be changed.

2.       Add code to change that PCI configuration in i40e PMD only, as it seems nobody else need it till now.

Regards,
Helin

From: David Marchand [mailto:david.marchand at 6wind.com]
Sent: Thursday, September 18, 2014 4:58 PM
To: Zhang, Helin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] i40e: Steps and required configurations of how to achieve the best performance!

Hello Helin,

On Thu, Sep 18, 2014 at 4:39 AM, Zhang, Helin <helin.zhang at intel.com<mailto:helin.zhang at intel.com>> wrote:
Hi David

From: David Marchand [mailto:david.marchand at 6wind.com<mailto:david.marchand at 6wind.com>]
Sent: Wednesday, September 17, 2014 10:03 PM
To: Zhang, Helin
Cc: dev at dpdk.org<mailto:dev at dpdk.org>
Subject: Re: [dpdk-dev] i40e: Steps and required configurations of how to achieve the best performance!

On Wed, Sep 17, 2014 at 10:50 AM, Zhang, Helin <helin.zhang at intel.com<mailto:helin.zhang at intel.com>> wrote:
For the ‘extended tag’, it was defined in PCIe spec, but actually not all BIOS implements it. Enabling it in BIOS or at runtime are two choices of doing the same thing. I don’t think it can be configured per PCI device in BIOS, so we don’t need to do that per PCI device in DPDK. Right? Actually we don’t want to touch PCIe settings in DPDK code, that’s why we want to let BIOS config as it is by default. If no better choice, we can do it in DPDK by changing configurations.

- Ok, then if we can make a runtime decision (at dpdk level), there is no need for bios configuration and there is no need for a build option.
Why don't we get rid of this option ?

[Helin] Initially, we want to do that for BIOS, if specific BIOS does not implement it. That way it needs to be initialized once during initialization for each PCI device. Sure, that might not be the best option, but it is the easiest way. For Linux end users, the best option could be using ‘setpci’ command. It can enable ‘extended_tag’ per PCI device.

I am not sure I can see how easy it is since you are forcing this in a build option.
Anyway, all this knowledge should be in the documentation and not in an obscure build option that looks to be useless in the end.

The more I look at this, the more I think we did not have good enough argument for this change in eal / igb_uio yet.

We have something that gives "better performance" on "some server" with "some bios".




As far as the per-device runtime configuration is concerned, I want to make sure this pci configuration will not break other "igb_uio" pci devices.
If Intel can tell for sure this won't break other devices, then fine, we can go and enable this for all "igb_uio" pci devices.

[Helin] It is in PCIe specification, and enable it can provide better performance generally. But I cannot confirm that it would not break any other devices, as I don’t validate all devices. If you really concern it, ‘setpci’ can be the best option for you. We can add a script for that later.

Why not a script, but documentation is important too: I would say that we need an explicit list of platforms and nics which support this.



- By the way, there is also the CONFIG_MAX_READ_REQUEST_SIZE option that seems to be disabled (or at least its value 0 seems to tell so).
What is its purpose ?

[Helin] Yes, it was added for performance tuning long long ago. But now it seems contribute nothing or too few for the performance number, so I just skip it. The default value does nothing on PCIe registers, just keep it as is.

Not so long ago to dpdk.org<http://dpdk.org> (somewhere around 1.7.0 ...).
If this code had no use for "so long", why did it end up on dpdk.org<http://dpdk.org> ?
Why should we keep it ?


Thanks.

--
David Marchand


More information about the dev mailing list