From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <vladz@cloudius-systems.com> Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by dpdk.org (Postfix) with ESMTP id 9D3E63787 for <dev@dpdk.org>; Thu, 1 Oct 2015 17:03:26 +0200 (CEST) Received: by wicfx3 with SMTP id fx3so32908963wic.0 for <dev@dpdk.org>; Thu, 01 Oct 2015 08:03:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=6vurjrmzlhgzvQH6yH0T2fDdJPd96k5SLloe+pVzTRg=; b=CjvWIuKgG6aXT+qnIOJqrzChyI0LD8mMntOxbJH6SpjXBZsBzCwZxHd3nxs7rX/Krv LuRnn0TA0SB5EAe+IqZQ8R+6zrGrJyLUYRMIGfEADGwowSeVL77NjCEkBr2r322D8iVq sLOtjI/qjhV0uXZ6o2t+pGw34/W1Agxw6rlrYbpuhfveiJtwcrMWvdQQjzb9Xdllpfkv QixeI9mSob+cmuf6czjoejHIxcI8Barx5xXD9vVDh1Dn9gZQ6c1edfPq7hFhHpFFC5FM 9TTa0Xt1PUBneYGOGgj/l8ux7huFvumOG8jLf/BaUYuGy3Mwiu2JEOSmt6pb5mABbrug xA2Q== X-Gm-Message-State: ALoCoQmdiPuliG1b6KpAYoywBJRAHsk8yv1kPR2JoekCSYveQXFADD8h+xWpbzsoftBhbpoJhWcz X-Received: by 10.180.103.167 with SMTP id fx7mr3619130wib.89.1443711806408; Thu, 01 Oct 2015 08:03:26 -0700 (PDT) Received: from [10.0.0.165] ([37.142.229.250]) by smtp.googlemail.com with ESMTPSA id jj8sm3643338wid.2.2015.10.01.08.03.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 08:03:25 -0700 (PDT) To: Stephen Hemminger <stephen@networkplumber.org> References: <20150930143927-mutt-send-email-mst@redhat.com> <560BCD2F.5060505@cloudius-systems.com> <20150930150115-mutt-send-email-mst@redhat.com> <560BD284.7040505@cloudius-systems.com> <20150930151632-mutt-send-email-mst@redhat.com> <560BDA81.6070807@cloudius-systems.com> <20150930182155-mutt-send-email-mst@redhat.com> <560C26DC.80209@cloudius-systems.com> <20150930215027-mutt-send-email-mst@redhat.com> <560C32CC.90708@cloudius-systems.com> <20150930222910-mutt-send-email-mst@redhat.com> <560C417D.1050409@cloudius-systems.com> <20150930143648.4b98db81@urahara> <560CE81C.3050004@cloudius-systems.com> <20151001074714.5f6cc100@urahara> From: Vlad Zolotarov <vladz@cloudius-systems.com> Message-ID: <560D4B3C.30907@cloudius-systems.com> Date: Thu, 1 Oct 2015 18:03:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151001074714.5f6cc100@urahara> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" <dev@dpdk.org>, "Michael S. Tsirkin" <mst@redhat.com> Subject: Re: [dpdk-dev] Having troubles binding an SR-IOV VF to uio_pci_generic on Amazon instance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 01 Oct 2015 15:03:26 -0000 On 10/01/15 17:47, Stephen Hemminger wrote: > On Thu, 1 Oct 2015 11:00:28 +0300 > Vlad Zolotarov <vladz@cloudius-systems.com> wrote: > >> >> On 10/01/15 00:36, Stephen Hemminger wrote: >>> On Wed, 30 Sep 2015 23:09:33 +0300 >>> Vlad Zolotarov <vladz@cloudius-systems.com> wrote: >>> >>>> On 09/30/15 22:39, Michael S. Tsirkin wrote: >>>>> On Wed, Sep 30, 2015 at 10:06:52PM +0300, Vlad Zolotarov wrote: >>>>>>>> How would iommu >>>>>>>> virtualization change anything? >>>>>>> Kernel can use an iommu to limit device access to memory of >>>>>>> the controlling application. >>>>>> Ok, this is obvious but what it has to do with enabling using MSI/MSI-X >>>>>> interrupts support in uio_pci_generic? kernel may continue to limit the >>>>>> above access with this support as well. >>>>> It could maybe. So if you write a patch to allow MSI by at the same time >>>>> creating an isolated IOMMU group and blocking DMA from device in >>>>> question anywhere, that sounds reasonable. >>>> No, I'm only planning to add MSI and MSI-X interrupts support for >>>> uio_pci_generic device. >>>> The rest mentioned above should naturally be a matter of a different >>>> patch and writing it is orthogonal to the patch I'm working on as has >>>> been extensively discussed in this thread. >>>> >>> I have a generic MSI and MSI-X driver (posted earlier on this list). >>> About to post to upstream kernel. >> Stephen, hi! >> >> I found the mentioned series and first thing I noticed was that it's >> been sent in May so the first question is how far in your list of tasks >> submitting it upstream is? We need it more or less yesterday and I'm >> working on it right now. Therefore if u don't have time for it I'd like >> to help... ;) However I'd like u to clarify a few small things. Pls., >> see below... >> >> I noticed that u've created a separate msi_msix driver and the second >> question is what do u plan for the upstream? I was thinking of extending >> the existing uio_pci_generic with the MSI-X functionality similar to >> your code and preserving the INT#X functionality as it is now: > The igb_uio has a bunch of other things I didn't want to deal with: > the name (being specific to old Intel driver); compatibility with older > kernels; legacy ABI support. Therefore in effect uio_msi is a rebase > of igb_uio. > > The submission upstream yesterday is the first step, I expect lots > of review feedback. Sure, we have lots of feedback already even before the patch has been sent... ;) So, I'm preparing the uio_pci_generic patch. Just wanted to make sure we are not working on the same patch at the same time... ;) It's going to enable both MSI and MSI-X support. For a backward compatibility it'll enable INT#X by default. It follows the concepts and uses some code pieces from your uio_msi patch. If u want I'll put u as a signed-off when I send it. > >> * INT#X and MSI would provide the IRQ number to the UIO module while >> only MSI-X case would register with UIO_IRQ_CUSTOM. > I wanted all IRQ's to be the same for the driver, ie all go through > eventfd mechanism. This makes code on DPDK side consistent with less > special cases. Of course. The name (uio_msi) is a bit confusing since it only adds MSI-X support. I mistakenly thought that it adds both MSI and MSI-X but it seems to only add MSI-X and then there are no further questions... ;) > >> I also noticed that u enable MSI-X on a first open() call. I assume >> there was a good reason (that I miss) for not doing it in probe(). Could >> u, pls., clarify? What about this?