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=-0.8 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 2C10AC35247 for ; Wed, 5 Feb 2020 15:36:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 09AB52082E for ; Wed, 5 Feb 2020 15:36:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727070AbgBEPg2 convert rfc822-to-8bit (ORCPT ); Wed, 5 Feb 2020 10:36:28 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:45743 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726592AbgBEPg1 (ORCPT ); Wed, 5 Feb 2020 10:36:27 -0500 Received: by mail-vs1-f68.google.com with SMTP id v141so1563256vsv.12 for ; Wed, 05 Feb 2020 07:36:27 -0800 (PST) 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:content-transfer-encoding; bh=nNSaYcuH3CLgDyaV+0jVr4gDCM9RLWpNWYCUwe4cHoA=; b=Ynebi0vqBTYuopNOgZUVaZOOiaOobpCTnA5jzFblMTlmvJXwI/ca6o4/hgXAAQmIF2 B2xN3/ZB8Mi1oXAD/QqmmNGa8rO19CIbUXmGCwDodzGQnfP6v88SZuSiA4JfLWYRgnaM YjBvVonektR/Wd0EMEOr8WU9jH72Vr+Ao0tKdncI2L8PIGwJpp36N0fe23OG+kt0sZwg BHcr28Qw7QMpGhGLhIbtJ/qQlebm8YTeO2CkbgVJ1O7YiOnfn6I34YaX51M14GW3f/Qp qv3ESRb2kk3oYePNng7oShmf8nVFU89nyUWOz3gGBmaU0LMhIBub/j2au8HHOV9qOgNi Dngw== X-Gm-Message-State: APjAAAVyL27bp4xxyrzOJpTW/TyjViwiIHzZNu58ZmFC8YJ2GW9nQ0Yw kJ1lBPQCQa3zO0fPYSr4CLMdg/DgrgsnWt+pcmk= X-Google-Smtp-Source: APXvYqyZMh/7MAeGwNb3rL5yBb9WjeNAb8Gs5PQ+IuMH2497GzsL1O0hTeLL11as0wv9mT+UNYLnkYGxdIz93W/RBnI= X-Received: by 2002:a67:31d8:: with SMTP id x207mr22785203vsx.192.1580916986822; Wed, 05 Feb 2020 07:36:26 -0800 (PST) MIME-Version: 1.0 References: <20200122203253.20652-1-lrizzo@google.com> <875zh2bis0.fsf@toke.dk> <953c8fee-91f0-85e7-6c7b-b9a2f8df5aa6@iogearbox.net> <87blqui1zu.fsf@toke.dk> <875zh2hx20.fsf@toke.dk> <87r1zpgosp.fsf@toke.dk> <87r1zog9cj.fsf@toke.dk> <87a76cfstd.fsf@toke.dk> In-Reply-To: <87a76cfstd.fsf@toke.dk> From: Luigi Rizzo Date: Wed, 5 Feb 2020 07:36:15 -0800 Message-ID: Subject: Re: [PATCH] net-xdp: netdev attribute to control xdpgeneric skb linearization To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Cc: Luigi Rizzo , Daniel Borkmann , netdev , Jesper Dangaard Brouer , "David S. Miller" , "Jubran, Samih" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Jan 24, 2020 at 1:28 PM Toke Høiland-Jørgensen wrote: > > Luigi Rizzo writes: > > > On Fri, Jan 24, 2020 at 7:31 AM Toke Høiland-Jørgensen wrote: > >> > >> Luigi Rizzo writes: > >> > > ... > >> > My motivation for this change is that enforcing those guarantees has > >> > significant cost (even for native xdp in the cases I mentioned - mtu > > >> > 1 page, hw LRO, header split), and this is an interim solution to make > >> > generic skb usable without too much penalty. > >> > >> Sure, that part I understand; I just don't like that this "interim" > >> solution makes generic and native XDP diverge further in their > >> semantics... > > > > As a matter of fact I think it would make full sense to use the same approach > > to control whether native xdp should pay the price converting to linear buffers > > when the hw cannot guarantee that. > > > > To me this seems to be a case of "perfect is enemy of good":.. > > Hmm, I can kinda see your point (now that I've actually grok'ed how the > length works with skbs and generic XDP :)). I would still worry that > only having the header there would lead some XDP programs to just > silently fail. But on the other hand, this is opt-in... so IDK - maybe > this is fine to merge as-is, and leave improvements for later? Sorry I let this slip, any consensus on this patch? Thanks Luigi -- -----------------------------------------+------------------------------- Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL +39-050-2217533 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -----------------------------------------+-------------------------------