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=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 97650C06513 for ; Thu, 4 Jul 2019 12:14:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 765AE218A3 for ; Thu, 4 Jul 2019 12:14:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727733AbfGDMOs (ORCPT ); Thu, 4 Jul 2019 08:14:48 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:35156 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727615AbfGDMOr (ORCPT ); Thu, 4 Jul 2019 08:14:47 -0400 Received: by mail-qk1-f194.google.com with SMTP id r21so5101123qke.2; Thu, 04 Jul 2019 05:14:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9cNGGl+FLilA8PMo/2823HsEW5aV7LEQGtBmo7DnFEc=; b=CM+vpFVspPTYEDMdGio5Ui9f86Lxh9bIBdEOQ40wOW2Cth2CmaKfsJuJNRac3WZesM hIXh1x3Hc15t1IlJ+FiYTYvLUlu7qefK5hkVyodgPF3jpy7ys7sZTt6XVw9CBOBsf8FL Pf/KRHPP7fQPRBFsgVOuDiM6qi2pcXoaKIBNfKdWkXeKVP7ari5H7NwH7xKL64OWllY7 C9i/2RpOiDXU7VN11NAfQ8LtnjP0OXVBs34D1aDLhUev28c/4cTprNrfamCbWysB8CFU F4xXJBas7rKl8wljGWN/QsdPzgWim3n9jV28Ri2qMDLfQt28MehKbFfuAnksp476OTBT /l6w== X-Gm-Message-State: APjAAAXLkvkchE09EP+Vb6NEaywCKXMdOPHue2ExUFrnAQCfoIpeDWce OgbXxks9gRpOH9uQj/6jTkVo5it/cw5YJrWh01k= X-Google-Smtp-Source: APXvYqzvpIz9J26dzCUH95aoNaSNG7JvaLf06oXPM82JIyYSrVI156uv/dpYNT0OS7IMkbIycWc7OMw2LwtS3sy2tBc= X-Received: by 2002:a37:76c5:: with SMTP id r188mr34670161qkc.394.1562242486886; Thu, 04 Jul 2019 05:14:46 -0700 (PDT) MIME-Version: 1.0 References: <1b254bb7fc6044c5e6e2fdd9e00088d1d13a808b.1562149883.git.joabreu@synopsys.com> <20190704120018.4523a119@carbon> <20190704103057.GA29734@apalos> In-Reply-To: <20190704103057.GA29734@apalos> From: Arnd Bergmann Date: Thu, 4 Jul 2019 14:14:28 +0200 Message-ID: Subject: Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool To: Ilias Apalodimas Cc: Jesper Dangaard Brouer , Jose Abreu , Joao Pinto , Alexandre Torgue , Maxime Ripard , Networking , Linux Kernel Mailing List , "David S . Miller" , Chen-Yu Tsai , Maxime Coquelin , Giuseppe Cavallaro , linux-stm32@st-md-mailman.stormreply.com, Linux ARM Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 4, 2019 at 12:31 PM Ilias Apalodimas wrote: > > On Wed, 3 Jul 2019 12:37:50 +0200 > > Jose Abreu wrote: > 1. page pool allocs packet. The API doesn't sync but i *think* you don't have to > explicitly since the CPU won't touch that buffer until the NAPI handler kicks > in. On the napi handler you need to dma_sync_single_for_cpu() and process the > packet. > So bvottom line i *think* we can skip the dma_sync_single_for_device() on the > initial allocation *only*. If am terribly wrong please let me know :) I think you have to do a sync_single_for_device /somewhere/ before the buffer is given to the device. On a non-cache-coherent machine with a write-back cache, there may be dirty cache lines that get written back after the device DMA's data into it (e.g. from a previous memset from before the buffer got freed), so you absolutely need to flush any dirty cache lines on it first. You may also need to invalidate the cache lines in the following sync_single_for_cpu() to eliminate clean cache lines with stale data that got there when speculatively reading between the cache-invalidate and the DMA. Arnd