From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03B139CA49 for ; Sun, 1 Oct 2023 11:57:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5F2CC433C8; Sun, 1 Oct 2023 11:57:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1696161448; bh=JsTcYuCjnKCRS49oBtoC/vqy3wZU5S1GK8S0OnCnZK4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=zaeTs7ygqGfjrJWOnFpfD3yxD4Vik2KbdPjbE0n2twJEyAqkuWttYUXY3y0MSydKM VgbDXZMTofVh3NjFuvBjRB+0g7QNWvqSbKpMModxj2vdeuN1iJey22rW1P4myyS8lf by8piuTx91mqiUPbju6XcRad0soc2YA8f92gTkJ4= Date: Sun, 1 Oct 2023 13:57:25 +0200 From: Greg Kroah-Hartman To: Hannes Reinecke Cc: Chris Leech , Christoph Hellwig , Rasesh Mody , Ariel Elior , Sudarsana Kalluru , Manish Chopra , Nilesh Javali , Manish Rangankar , Jerry Snitselaar , John Meneghini , Lee Duncan , Mike Christie , Hannes Reinecke , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] cnic,bnx2,bnx2x: use UIO_MEM_DMA_COHERENT Message-ID: <2023100114-flatware-mourner-3fed@gregkh> References: <20230929170023.1020032-1-cleech@redhat.com> <20230929170023.1020032-4-cleech@redhat.com> <2023093055-gotten-astronomy-a98b@gregkh> <2023093002-unlighted-ragged-c6e1@gregkh> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sun, Oct 01, 2023 at 12:44:05PM +0200, Hannes Reinecke wrote: > On 9/30/23 20:28, Greg Kroah-Hartman wrote: > > On Sat, Sep 30, 2023 at 11:19:20AM -0700, Chris Leech wrote: > > > On Sat, Sep 30, 2023 at 09:06:51AM +0200, Greg Kroah-Hartman wrote: > > > > On Fri, Sep 29, 2023 at 10:00:23AM -0700, Chris Leech wrote: > > > > > Make use of the new UIO_MEM_DMA_COHERENT type to properly handle mmap > > > > > for dma_alloc_coherent buffers. > > > > > > > > Why are ethernet drivers messing around with UIO devices? That's not > > > > what UIO is for, unless you are trying to do kernel bypass for these > > > > devices without anyone noticing? > > > > > > > > confused, > > > > > > It's confusing. The bnx2 driver stack included a cnic (converged nic?) > > > module that sits between the ethernet drivers (bnx2, bnx2x) and protocol > > > offload drivers (iscsi, fcoe, rdma). > > > > > > The iscsi module (bnx2i) uses a passthrough interface from cnic to > > > handle some network configuration that the device firmware doesn't do. > > > It uses a uio device and a userspace component called iscsiuio to do > > > that. > > > > That's horrible, and not what the UIO api is for at all. Configure the > > device like any other normal kernel device, don't poke at raw memory > > values directly, that way lies madness. > > > > Have a pointer to the userspace tool anywhere? All I found looks like a > > full IP stack in userspace under that name, and surely that's not what > > this api is for... > > > But that's how the interface is used, in particular for the bnx2i driver. > Problem is that the bnx2i iSCSI offload is just that, an iSCSI offload. Not > a TCP offload. So if the iSCSI interface is configured to > acquire the IP address via DHCP, someone has to run the DHCP protocol. > But the iSCSI offload can't, and the bnx2i PCI device is not a network > device so that the normal network stack can't be used. > And so the architects of the bnx2i card decided to use UIO to pass > the network traffic to userspace, and used the userspace 'iscsiuio' > application to run DHCP in userspace. > > But's been that way for several years now; so long, in fact, that > the card itself has been out of support from Marvell (since quite some > years, too, IIRC). And even the successor of that card (the qedi driver) > is nearing EOL. Mind you, the qedi driver is using the same interface (by > using UIO to run DHCP in userspace), so singling out the bnx2i for bad > design can be construed as being unfair :-) Ok, let's say they are all horrible! :) > I agree, though, that the design is a mess. Ok, so why are we papering over it and continuing to allow it to exist? What "broke" to suddenly require this UIO change? If this has been around for a very long time, what has caused this to now require the UIO layer to change? thanks, greg k-h