From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com [209.85.161.170]) by dpdk.org (Postfix) with ESMTP id 0A73B5946 for ; Thu, 12 May 2016 07:54:14 +0200 (CEST) Received: by mail-yw0-f170.google.com with SMTP id j74so63844368ywg.1 for ; Wed, 11 May 2016 22:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=b6EZwwCGlELtkf4RZyioLP0rGckX0wRIVXmEsD/8elw=; b=Uouw32+tTHBChenJjJPAJzm7oAHKeLuB9DHAuobyema/6uu9Lhr6cngxlJEnXJTOpP fZeCD87+/PhjG4yinS8sQ7NFnupN7s+o8huAxDmpBlwfduTz+wSDeROSE+jn9KlLpVj+ Jk0JykAHFOTH7oNl90b7qqsY1bCo8twC5UGsQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=b6EZwwCGlELtkf4RZyioLP0rGckX0wRIVXmEsD/8elw=; b=AhwoQs/F6lZPxHOe3oJSnUb0SKsa19RZwx/Wr+f5wxDDGb4ut9498rJzahXpKTNr1a 2Qo3KKNn/VVOq8e+jVJbLAenAtcklwo6l1E4Tq3OMS4DKA0jmb189MUphMvj9d7dPT1v eWnLlUgyE1DbRoBnGDsV3fn0n9KapLkiAvJkINuWaJ8l8lFggOdCrLZeNJ5bIYPeyIct A73Deg9ECDwoFiB66BSp7At/vCiAHpkF80TfaFKJpb/lnVJjpIO6ssWUDetAeyH6aLxV B9gBspgUI3bc/IgSRQQlQIdYsXByGLdQWd0gtrAYn6esx/ZTzBv44ZCrRdM2kTdoNZuI Yhng== X-Gm-Message-State: AOPr4FWcoFyPTRQHM/ZbKnX4yytkfzpq3y6IQZI+2TYe/jK/8zrGr+RL6PfOVzTy9Dp3ROLWsXVjE9eJoYrqFQ5m MIME-Version: 1.0 X-Received: by 10.13.247.4 with SMTP id h4mr4012935ywf.15.1463032453428; Wed, 11 May 2016 22:54:13 -0700 (PDT) Received: by 10.37.223.2 with HTTP; Wed, 11 May 2016 22:54:13 -0700 (PDT) In-Reply-To: <20160512050638.GA7301@santosh-Latitude-E5530-non-vPro> References: <1462974479-26180-1-git-send-email-hemant.agrawal@nxp.com> <20160511082259.42905f98@xeon-e3> <20160511170215.GA1637@localhost.localdomain> <20160511112559.69dcff13@xeon-e3> <20160512031642.GA5855@santosh-Latitude-E5530-non-vPro> <20160512050638.GA7301@santosh-Latitude-E5530-non-vPro> Date: Thu, 12 May 2016 13:54:13 +0800 Message-ID: From: Jianbo Liu To: Santosh Shukla Cc: Stephen Hemminger , Jerin Jacob , Hemant Agrawal , dev@dpdk.org, Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Subject: Re: [dpdk-dev] [PATCHv3 1/2] config/armv8a: disable igb_uio X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 05:54:14 -0000 On 12 May 2016 at 13:06, Santosh Shukla wrote: > On Thu, May 12, 2016 at 11:42:26AM +0800, Jianbo Liu wrote: >> On 12 May 2016 at 11:17, Santosh Shukla >> wrote: >> > On Thu, May 12, 2016 at 10:01:05AM +0800, Jianbo Liu wrote: >> >> On 12 May 2016 at 02:25, Stephen Hemminger wrote: >> >> > On Wed, 11 May 2016 22:32:16 +0530 >> >> > Jerin Jacob 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 wrote: >> >> >> > >> >> >> > > IGB_UIO not supported for arm64 arch in kernel so disable. >> >> >> > > >> >> >> > > Signed-off-by: Hemant Agrawal >> >> >> > > Reviewed-by: Santosh Shukla >> >> >> > >> >> >> > 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