From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C768EC43219 for ; Fri, 26 Apr 2019 22:02:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9060E206C1 for ; Fri, 26 Apr 2019 22:02:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="yJNjghie" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727083AbfDZWCv (ORCPT ); Fri, 26 Apr 2019 18:02:51 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:46217 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726632AbfDZWCv (ORCPT ); Fri, 26 Apr 2019 18:02:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BS5MJiT5HrdcX3ERI95iiVbRC6UTS1Yq0TpvT2OvyNg=; b=yJNjghie4ikHXySQNMVKjndVHE rv1NmCt7iT45nhais9PC7Tz8u7Jvg4rS1TgRVnl6qwd6KRVys40o1P9kB1Ha8txSUrgBeTGoXKF9S BE3k8Gkw8gcQVHz2BRVNKlnIVvIY1xCVIjuizm4LJirqC0Rhl2Rjy33JYKzI7CejzILg=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1hK8vK-0005ys-RR; Sat, 27 Apr 2019 00:02:26 +0200 Date: Sat, 27 Apr 2019 00:02:26 +0200 From: Andrew Lunn To: Jakub Kicinski Cc: Esben Haabendal , netdev@vger.kernel.org, "David S. Miller" , Michal Simek , Yang Wei , YueHaibing , Luis Chamberlain , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 03/12] net: ll_temac: Fix support for 64-bit platforms Message-ID: <20190426220226.GW4041@lunn.ch> References: <20190426073231.4008-1-esben@geanix.com> <20190426073231.4008-4-esben@geanix.com> <20190426114013.333e62c8@cakuba.netronome.com> <20190426205912.GI4041@lunn.ch> <20190426140856.78b786ee@cakuba.netronome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190426140856.78b786ee@cakuba.netronome.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 26, 2019 at 02:08:56PM -0700, Jakub Kicinski wrote: > On Fri, 26 Apr 2019 22:59:12 +0200, Andrew Lunn wrote: > > On Fri, Apr 26, 2019 at 11:40:13AM -0700, Jakub Kicinski wrote: > > > On Fri, 26 Apr 2019 09:32:22 +0200, Esben Haabendal wrote: > > > > The use of buffer descriptor APP4 field (32-bit) for storing skb pointer > > > > obviously does not work on 64-bit platforms. > > > > As APP3 is also unused, we can use that to store the other half of 64-bit > > > > pointer values. > > > > > > > > Contrary to what is hinted at in commit message of commit 15bfe05c8d63 > > > > ("net: ethernet: xilinx: Mark XILINX_LL_TEMAC broken on 64-bit") > > > > there are no other pointers stored in cdmac_bd. > > > > > > > > Signed-off-by: Esben Haabendal > > > > > > This is a bit strange, the driver stores the host's virtual address into > > > the HW descriptor? Lets try that again Hi Jakub > > Hi Jukub > > I need to start keeping track of all the ways my name gets spelled :) > I find it entertaining :) Sorry. And i prefer entertaining over offended :-) > > This is reasonably common. You need some sort of cookie which links > > the hardware descriptor to the skbuf it points to. The hardware makes > > no use of it, it is just a cookie. > > Right, but accesses to HW descriptor memory ring are significantly > more expensive, especially on platforms which are not coherent with > DMA operations (everything but x86?) > > A preferable design is to have two descriptor rings - one for HW > descriptors and one for software context, no? Modern drivers do that. But this driver seems to be quite old. And if you look at what it is used on, PPC & MICROBLAZE, they are old architectures, i don't think hardware access are that as expensive as for modern architectures. Andrew