From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by mail.toke.dk (Postfix) with ESMTPS id 4B74B9C8E25 for ; Thu, 1 Dec 2022 01:32:59 +0100 (CET) Authentication-Results: mail.toke.dk; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20210112 header.b=LVy0wqAJ Received: by mail-oi1-x229.google.com with SMTP id e205so395555oif.11 for ; Wed, 30 Nov 2022 16:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lN9JwId4tiOiae0xE/P7QQ4kvD0YngnrPqvp/M5Dfwg=; b=LVy0wqAJnY3VNQt12119+LCZMGKEGZ4EZUpcDF8EAoT4pmN0KnCQU55BD8KghUPtIz ZsT8L+j+0sUolshFFwaUdBMQt4DGYv65Q49zXJCc3UdtV//RlNncelI034mQRlVKY+83 Usk1Kn7mUIVEENTh0Bydb+XC96fHUi61pBOK2wk/LJhu9lQXZHwG1PpmBFGFDGMLHnwW fDm17V+un9o+gaMu8s7TnWPKJuBYkZ4LXTezcYWwysJKVnrBDc/kdlV3cmRU9fJWU5BG AaBNCGUQ1GBrxhyAtgvrZopjh3Oz8lEyV/GjE4qNPyxq7vY7hBSkcL3FeA36SbLRaHHv XT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lN9JwId4tiOiae0xE/P7QQ4kvD0YngnrPqvp/M5Dfwg=; b=rbbk9ZK908SKnvvHW9AZanDw5fXXksXBddsyxCzKSSZZhi1j13ZFZLhQpDpTHww6OI CL7HNGwXv3RlcBviZrHno/DQmiRzHBxZp8s9/pTQI6nzMF+P70V+/GpovauB6nrDO3mm jumVCxbeUc6NO1NrxaS4WJFNV4x6FAQnHrkB7VRmsP7XBNtlxs4IgVnOKJo9er8dB2UD I2fyfkJJWQ1MuL+KUtU8LCTsEj9ws5S16qD9SGLe8e1ANNNZjKYI4Cpfao3xBIJf++je aJYgEThBrscfHuq1btJ8Dhke3ERrIeBXghPmF+5qLLoDMzPPoi+qCPhWb4kPwHf/fzMd ly8A== X-Gm-Message-State: ANoB5plGwoGaZ/AeK7I8UkPebQWHfpuCTL7bCp2dwgu+uFQN31N3rA3W sDCrfRcYslQWnEhSeAu0Cl69vHpYZR7lL2nymf9aJw== X-Google-Smtp-Source: AA0mqf530DwVXRBjyS1VDdG0iUR9zIZ+cLsrFMslgltcHCQTdc4+KU6TyFgLBaQ7cGl5k9xwLyZmJYMAb7AgD0mCR/o= X-Received: by 2002:aca:d01:0:b0:35b:d6f7:c569 with SMTP id 1-20020aca0d01000000b0035bd6f7c569mr1985835oin.125.1669854778144; Wed, 30 Nov 2022 16:32:58 -0800 (PST) MIME-Version: 1.0 References: <20221129193452.3448944-1-sdf@google.com> <8735a1zdrt.fsf@toke.dk> <87o7soxd1v.fsf@toke.dk> <07db58dd-0752-e148-8d89-e22b8d7769f0@linux.dev> In-Reply-To: <07db58dd-0752-e148-8d89-e22b8d7769f0@linux.dev> From: Stanislav Fomichev Date: Wed, 30 Nov 2022 16:32:47 -0800 Message-ID: To: Martin KaFai Lau Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: S6IDCDVZSO3R73OJD7IZPT6FZ5CJ5JYC X-Message-ID-Hash: S6IDCDVZSO3R73OJD7IZPT6FZ5CJ5JYC X-MailFrom: sdf@google.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, song@kernel.org, yhs@fb.com, john.fastabend@gmail.com, kpsingh@kernel.org, haoluo@google.com, jolsa@kernel.org, David Ahern , Jakub Kicinski , Willem de Bruijn , Jesper Dangaard Brouer , Anatoly Burakov , Alexander Lobakin , Magnus Karlsson , Maryam Tahhan , xdp-hints@xdp-project.net, netdev@vger.kernel.org, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= X-Mailman-Version: 3.3.7 Precedence: list Subject: [xdp-hints] Re: [PATCH bpf-next v3 00/11] xdp: hints via kfuncs List-Id: XDP hardware hints design discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Wed, Nov 30, 2022 at 4:16 PM Martin KaFai Lau wro= te: > > On 11/30/22 3:01 PM, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >> It feels like beyond that extra dev_put, we'd need to reset our > >> aux->xdp_netdev and/or add some flag or something else to indicate > >> that this bpf program is "orphaned" and can't be attached anywhere > >> anymore (since the device is gone; netdev_run_todo should free the > >> netdev it seems). > > imo, orphan the prog and not able to attach again is ok. Finding the nex= t > compatible netdev would be nice but not a must to begin with. Regardless= , it > needs a bpf_prog<->netdev decoupling approach which allows to unregister = netdev > gracefully instead of getting the "unregister_netdevice: waiting for xyz = to > become free...". > > fwiw, offload.c has solved a similar problem and it keeps its own list of= prog > depending on a particular netdev. Whatever approach makes more sense her= e. > Ideally, other non-NIC HW kfunc can reuse a similar approach in the futur= e. Makes sense. Let me take a closer look. I glanced at it last week and decided that maybe it's easier to not hold the device at all.. Maybe we should have something like this: - bpf_prog_is_dev_bound() - prog is dev bound but not offloaded (currently bpf_prog_is_dev_bound =3D=3D fully offloaded) - bpf_prog_is_offloaded() - prog is dev bound and offloaded So hopefully I can leverage some/most existing bpf_prog_is_dev_bound call sites (+ add some more to reject prog_run/etc).