Re: [dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio

[Jianbo Liu <jianbo.liu@linaro.org>]

On 12 May 2016 at 13:06, Santosh Shukla
<santosh.shukla@caviumnetworks.com> wrote:
> On Thu, May 12, 2016 at 11:42:26AM +0800, Jianbo Liu wrote:
>> On 12 May 2016 at 11:17, Santosh Shukla
>> <santosh.shukla@caviumnetworks.com> wrote:
>> > On Thu, May 12, 2016 at 10:01:05AM +0800, Jianbo Liu wrote:
>> >> On 12 May 2016 at 02:25, Stephen Hemminger <stephen@networkplumber.org> wrote:
>> >> > On Wed, 11 May 2016 22:32:16 +0530
>> >> > Jerin Jacob <jerin.jacob@caviumnetworks.com> wrote:
>> >> >
>> >> >> On Wed, May 11, 2016 at 08:22:59AM -0700, Stephen Hemminger wrote:
>> >> >> > On Wed, 11 May 2016 19:17:58 +0530
>> >> >> > Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
>> >> >> >
>> >> >> > > IGB_UIO not supported for arm64 arch in kernel so disable.
>> >> >> > >
>> >> >> > > Signed-off-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>> >> >> > > Reviewed-by: Santosh Shukla <santosh.shukla@caviumnetworks.com>
>> >> >> >
>> >> >> > Really, I have use IGB_UIO on ARM64
>> >> >>
>> >> >> May I know what is the technical use case for igb_uio on arm64
>> >> >> which cannot be addressed through vfio or vfioionommu.
>> >> >
>> >> > I was running on older kernel which did not support vfioionommu mode.
>> >>
>> >> As I said, most of DPDK developers are not kernel developers. They may
>> >> have their own kernel tree, and couldn't like to upgrade to latest
>> >> kernel.
>> >> They can choose to use or not use igb_uio when binding the driver. But
>> >> blindly disabling it in the base config seems unreasonable.
>> >
>> > if user keeping his own kernel so they could also keep IGB_UIO=y in their local
>> Most likely they don't have local dpdk tree. They write their own
>> applications, complie and link to dpdk lib, then done.
>>
>> > dpdk tree. Why are you imposing user-x custome depedancy on upstream dpdk base
>> Customer requiremnts is important. I want they can choose the way they like.
>>
>
> so you choose to keep igb_uio option, provided arch doesn't support?
> new user did reported issues with igb_uio for arm64, refer this thread [1], as
> well hemanth too faced issues. we want to avoid that.
>
> If customer maintaing out-of-tree kernel then he can also switch to vfio-way.
> isn;t it?
>
>> > config. Is it not enough for explanation that - Base config ie.. armv8 doesn;t
>> > support pci mmap, so igb_uio is n/a. New user wont able to build/run dpdk/arm64
>> > in igb_uio-way, He'll prefer to use upstream stuff. I think, you are not making
>> You are wrong, he can build dpdk. If he like to use upstream without
>> patching, he can use vfio.
>
> I disagree, we want to avoid [1] for new user.
>
>> But you can't ignore the need from old user which is more comfortable
>> with older kernel.
>>
> arm/arm64 dpdk support recently added and I am guessing, most likely customer
> using near latest kernel, switching to vfio won't be so difficult.
>
> Or can you take up responsibility of upstreaming pci mmap patch, then we don't
> need this patch.
>
> [1] http://dpdk.org/ml/archives/dev/2016-January/031313.html

Can you read carefully about the guide at
http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html? It says to use
uio_pci_generic, igb_uio or vfio-pci.
Could it be possible that the user in that thread has already read and
tried them all and found that he can't enable vifo with his kernel,
and igb_uio is the easy way for him and asked for help from community?
If so, we have no choice but keeping igb_uio enabled.

He use lsmod to show us the modules, most likely he know vifo-pci.

Below are the details on modules, hugepages and device binding.
root at arm64:~# lsmod
Module                  Size  Used by
rte_kni               292795  0
igb_uio                 4338  0
ixgbe                 184456  0