Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 25 Apr 2023 11:56:57 +0200
From:   Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To:     Kal Cutter Conley <kal.conley@dectris.com>
CC:     John Fastabend <john.fastabend@gmail.com>,
        =?iso-8859-1?Q?Bj=F6rn_T=F6pel?= <bjorn@kernel.org>,
        Magnus Karlsson <magnus.karlsson@intel.com>,
        Jonathan Lemon <jonathan.lemon@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "Alexei Starovoitov" <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        "Jesper Dangaard Brouer" <hawk@kernel.org>,
        <netdev@vger.kernel.org>, <bpf@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] xsk: Use pool->dma_pages to check for DMA
Message-ID: <ZEej6ZJVAgzRueyA@boxer>
References: <20230423075335.92597-1-kal.conley@dectris.com>
 <6446d34f9568_338f220872@john.notmuch>
 <CAHApi-=Vr4VARgoDNB1T906gfDNB5L5_U24zE=ZHQi+qd__e8w@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHApi-=Vr4VARgoDNB1T906gfDNB5L5_U24zE=ZHQi+qd__e8w@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?5+nrMytWkROLezeC7oxUFcgOtVNottTQgH8CkLAf1tsidTDqxVV9ugNcm/XI?=
 =?us-ascii?Q?LHLuaeRvvSQlhobP2+JY1PR9UukAYGPTDSDX9nUImZtLeQMFKMYBNFt31jQ4?=
 =?us-ascii?Q?c2GTHW1ftBqvPqCAG2nkLGOuG12NoJvZNR8BIgSLpbDhk5TbAzBZogTq1Zhx?=
 =?us-ascii?Q?rPlxjQ39Tp6JZO7K0X1hgEnJP1g9LMNuN+c8v1wBmfJ2terACGx6GGMLUQib?=
 =?us-ascii?Q?Fxf60TnHPgNVfCoOKDtsGQ+afSS1wYWRwxanBqOHXHyrEDoP5chdOMRAfww3?=
 =?us-ascii?Q?5UJ8Pgo0wdVuVQLNgCS3APBRuzW2SXmhp3mWeCdyDXdzZOyj61ATw8hmQVQS?=
 =?us-ascii?Q?EXB3hQyJwtBYDTzUcStm4lS7AEzFeO9yB8X7mCg+z0dM8X3GjL3K2WitVOeP?=
 =?us-ascii?Q?6m2EU3QD63Tr/zkC6h8nXFOCnsutHweYFGBAl6sVfXAP6zkhFx/U+Q58BK0J?=
 =?us-ascii?Q?1xN7pawvNwVv9gLBWuWC3OgfYSCqT3kpoCSfchB86HL/69FRfWCGQtlcyBOP?=
 =?us-ascii?Q?slGkle81yhh7lWIJSZ33RZAH/TqCfzrIpGMoYl7RQbWX8kFA72tTqzOKCcVR?=
 =?us-ascii?Q?JcSf2N0QdU3sF+R7k60b20cHYr1YCjClb+EmRyeFZLSRLpSlx/RpM6mfko2n?=
 =?us-ascii?Q?KgxuB2NZyPf1KkTlzxf9wV/9jlb+HUeTyc3L4Qk0UgTbWGwvSPNyGRUQSZWX?=
 =?us-ascii?Q?2TtpDvC4UK2zdwpAT88ox8N913N+a6YVr0ViVqbXzsqMY9tzjUUfPLIdbRNN?=
 =?us-ascii?Q?Xxa+T+jvclMvRMf5mg3terxG8v+UkLMWVGYr5KjdsPJ5Y6PwYyLN2PpsfrrN?=
 =?us-ascii?Q?l+nIScEx66EKumV2KSvpAxVwkxQ+09ws79B2hOZu0NDWEbKt5rFBGKXzbd30?=
 =?us-ascii?Q?O4FVmHqz83Uk5fToT66R7HQiRawH09wFsPgcCGMwoc87CP6AqRw6O5M00C8H?=
 =?us-ascii?Q?Ru30wETh9LTunWTezP2slGoCtw/jO8jkxe/KrAjjbWjr1Xvp86uM5FjC00/5?=
 =?us-ascii?Q?qqtVu8I6sFzGt6AcSjL9wClkLPN+o/UmrY7FjM8cH81Ek5gc7vUkrOeyxK2v?=
 =?us-ascii?Q?qJ5tP9dXIaxuvdEP+fzyun+k+rwm3MOeBXC+uy/PcE5MNIc74GXAsn0RnOEZ?=
 =?us-ascii?Q?uZfg3s/ixsPQ2TXWI9RT+ONphelpCGXhqcvRzbFZNDi3nbN768KjBGJ34qYX?=
 =?us-ascii?Q?cXCX+FATI9cPDXZTRMXPe9oJwoDa6RR3Ve3g94y2nTdbaeBSRlAC7JZp1p8b?=
 =?us-ascii?Q?DRnBpzYmRRFTL1EJu4LQEr2YA5gEYGlIGeDQ1pairGuwIZe/e5Qg3qBQVC5W?=
 =?us-ascii?Q?KmpnZXCzjPo4OUvefvNaMIXlAHRRHPha2jnKuxEaMPrcBYF9qXKPUfc7YTuo?=
 =?us-ascii?Q?d7Y4CNXD3roLkZiuEcZ80notYf1Mkel/QXv4pk+1/MztQ2Yt8kwYpmqtN7X+?=
 =?us-ascii?Q?OzVuHh4OJbAa9h4F8xh28CK4T8FmS+3nq2qo8iOVT178+NULsja4+882e8yr?=
 =?us-ascii?Q?d+3Nr1xZKhbW8TP+ZUEiYh3/BHxYERFrdA2NrYCIQTyPVnnzgo0mYQWeryvJ?=
 =?us-ascii?Q?oKNz7TSLECombi30327gU/+ielezLkph4eaKk6wo3qNwK6O0J12lPEEjaUqR?=
 =?us-ascii?Q?Bg=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: bad466d7-0571-4937-c729-08db45736f49
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6117.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2023 09:57:09.6441
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: fWu2OvvBjCKrYPgJAagaZ4eAx57Jf/JH9dC6vDcCpL1MnBZsJW5Yn7N1qeBlmSRz4fMnNA9NBWgssZ/zTVLSKYfvzSgVN9nVl/BVr4FPt60=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5252
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Apr 25, 2023 at 12:52:53AM +0200, Kal Cutter Conley wrote:

Hey again!

> > > Compare pool->dma_pages instead of pool->dma_pages_cnt to check for an
> > > active DMA mapping. pool->dma_pages needs to be read anyway to access
> > > the map so this compiles to more efficient code.
> >
> > Was it noticable in some sort of performance test?
> 
> This patch is part of the patchset found at
> https://lore.kernel.org/all/20230412162114.19389-3-kal.conley@dectris.com/
> which is being actively discussed and needs to be resubmitted anyway
> because of a conflict. While the discussion continues, I am submitting
> this patch by itself because I think it's an improvement on its own
> (regardless of what happens with the rest of the linked patchset). On
> one system, I measured a performance regression of 2-3% with xdpsock
> and the linked changes without the current patch. With the current
> patch, the performance regression was no longer observed.

Okay, 2-3% but with what settings? rxdrop for unaligned mode? what chunk
size etc? We need this kind of info, "compiles to more efficient code"
from original commit message is too generic and speculative to me. 2-3% of
perf diff against specific xdpsock setup is real improvement and is a
strong argument for getting this patch as-is, by its own.

> 
> > > diff --git a/include/net/xsk_buff_pool.h b/include/net/xsk_buff_pool.h
> > > index d318c769b445..a8d7b8a3688a 100644
> > > --- a/include/net/xsk_buff_pool.h
> > > +++ b/include/net/xsk_buff_pool.h
> > > @@ -180,7 +180,7 @@ static inline bool xp_desc_crosses_non_contig_pg(struct xsk_buff_pool *pool,
> > >       if (likely(!cross_pg))
> > >               return false;
> > >
> > > -     return pool->dma_pages_cnt &&
> > > +     return pool->dma_pages &&
> > >              !(pool->dma_pages[addr >> PAGE_SHIFT] & XSK_NEXT_PG_CONTIG_MASK);
> > >  }
> 
> I would consider the above code part of the "fast path". It may be
> executed approximately once per frame in unaligned mode.
> 
> > This seems to be used in the setup/tear-down paths so your optimizing
> > a control side. Is there a fast path with this code? I walked the
> > ice driver. If its just setup code we should do whatever is more
> > readable.
> 
> It is not only used in setup/tear-down paths (see above).
> Additionally, I believe the code is also _more_ readable with this
> patch applied. In particular, this patch reduces cognitive complexity
> since people (and compilers) reading the code don't need to
> additionally think about pool->dma_pages_cnt.

John was referring to xp_dma_unmap() with the comment above which indeed
is a teardown path, so probably this doesn't matter from performance
perspective and you could avoid this chunk from your patch.

> 
> > Both the _alloc_ cases read neighboring free_heads_cnt so your saving a load I guess?
> > This is so deep into micro-optimizing I'm curious if you could measure it?
> 
> It is saving a load which also reduces code size. This will affect
> other decisions such as what to inline. Also in the linked patchset,
> dma_pages and dma_pages_cnt do not share a cache line (on x86_64).

Yes I believe that the with your patch on unaligned mode by touching the
dma_pages you're warming the relevant cache line for your setup.

> 
> >
> > >               } else {
> > >                       xskb = &pool->heads[xp_aligned_extract_idx(pool, addr)];
> >
> > I'm not actually against optimizing but maybe another idea. Why do we have to
> > check at all? Seems if the DMA has been disabled/unmapped the driver shouldn't
> > be trying to call xsk_buff_alloc_batch? Then you can just drop the 'if' check.
> >
> > It feels to me the drivers shouldn't even be calling this after unmapping
> > the dma. WDYT?
> 
> Many of these code paths are used both for ZC and copy modes. You
> might be right that this particular case is only used with DMA.

Map/unmap is when you do ZC, copy/skb mode work without these internal dma
mappings.