Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Thu, 14 Sep 2023 19:04:26 +0200
From:   Larysa Zaremba <larysa.zaremba@intel.com>
To:     Stanislav Fomichev <sdf@google.com>
CC:     <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
        "Daniel Borkmann" <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        "Martin KaFai Lau" <martin.lau@linux.dev>,
        Song Liu <song@kernel.org>,
        Yonghong Song <yonghong.song@linux.dev>,
        John Fastabend <john.fastabend@gmail.com>,
        "KP Singh" <kpsingh@kernel.org>, Hao Luo <haoluo@google.com>,
        Jiri Olsa <jolsa@kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next] bpf: Allow to use kfunc XDP hints and frags
 together
Message-ID: <ZQM9GjMLo32SqxyQ@lincoln>
References: <20230914083716.57443-1-larysa.zaremba@intel.com>
 <ZQM1BUzcZQtXusA3@google.com>
 <ZQM5kt8qHKUH0Iob@lincoln>
 <CAKH8qBuw68AixQabgP5wNfAQBcc0RuVNEyV9rf9vgVi__c4Y9A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAKH8qBuw68AixQabgP5wNfAQBcc0RuVNEyV9rf9vgVi__c4Y9A@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Z054UkpBSW41RGx4ZHdOdDNwb0toUVZXMCtsdzZ6dHdZWDJSd0t5cU5MTU1L?=
 =?utf-8?B?SjV0LzEreHJXZ1ZCNVBML3BWZW1nNCtuZ0o2V09UclVhY0o2d1VtM25JREs4?=
 =?utf-8?B?bGJielNVa0hCZ2Q2U1BmN25VVVJldmpaWllPaFFrbWdUUWQwUGtOWVMwLzIw?=
 =?utf-8?B?cmU4REhBdXduTDNXWHdHU0E5a0NKcHMzcW9CQ0JXOVNGRCtoelFUYUcyRFY1?=
 =?utf-8?B?dkthbWlGSjV4ckxsTFVLODkrM2prNStHeXhkZWNudVFWOWVoUzFaN3c2OGFN?=
 =?utf-8?B?YWh5M1gweERsd200dGRiSGpDaWpGMURmQkZ5Rm0wbFY0QUxneFoxcDMwWWVh?=
 =?utf-8?B?THJ5d1FZR3Qyb3dkNW9BMC9hdGM2RnpwSGZ4UG8wTFV5alZFMmg1dUZRbDJa?=
 =?utf-8?B?NmlHWEgrTWdOOHd1UXBLOHl0UXJBTlQzMXMwdEwvWUdKU0Z5NjZTc2FDZ2ln?=
 =?utf-8?B?TzNPMldIem1teDJkOUwwUG42NkRRZ0ltaUlQMFJWUkxocldNbU9maUUxNWtr?=
 =?utf-8?B?SCs5QXRqQ3gzYmVKMHdwTEpqUWVnMUdsdnIvS0txL1AyVzlyUUFQbWx5T0VX?=
 =?utf-8?B?ODZ0ZGN3VEpSWGlsUHBBelFFS0RYT1VRQUZDQ1h3ZExUcDlvaHJPUFIrVWY2?=
 =?utf-8?B?dHZ6dmdHWkxwU3BvVHp1T2h4U1BjTG1MeU8vSDJVVW1MU0tocFQrVjhmLy9D?=
 =?utf-8?B?U1k3akl0ekgwSGZnRFlXMFcrc1FhWjIrTmxNWmQ4VVExV3laTW5xN2RWZ2pM?=
 =?utf-8?B?QjFDM0xWRmFlSXR1ZmE3YjBkSU9BYmVjaEtwbVk5M2NBYVF0aWtibXMyeTNY?=
 =?utf-8?B?ZHpQQkNvQXo1TFh6cUNBOGoreWV1NDZjZkJiZUNXa0M1cm0vWGkzbGx4VFBx?=
 =?utf-8?B?OHR5cUpXSVhqWG5vanVTWE1mK2dlcXFHQ0JLdFllTDdTWXNiYUJZRGh5dzZ1?=
 =?utf-8?B?VHRLUFB1b1dtREtza0FwSDJJaElPbTlvRUxhZ0wwVGxjZDU3YzFTRFVsRnRX?=
 =?utf-8?B?Q0NTSm1ZTzFyeGRUVTZhcDdGL2h4NGFSaVhlWEIvWmVaZXN4c0NoTm9TbzEx?=
 =?utf-8?B?ZTRaVTR5R2N5Y0VSY1dFMHE2cnVoL0d6RmhsNCtzdU1RWm05dGM3cGdrdnJy?=
 =?utf-8?B?Vno1aFdjR2Z3aUxjbkgxaXJJeWRqb1hmQmtDSzdvaDNqWlRBVktxbVRPTUxN?=
 =?utf-8?B?V0RhSVMyVGJaUU04WU9TNlprKzluK29ZWFZhWm9pZVNyN0M5WndUNFJTdTBK?=
 =?utf-8?B?L0taY1NRNzNQSmsvWlR3S0xNRXN6N01Ha0ozeVRqMzQ0K2g2TDNpczhqRjQ0?=
 =?utf-8?B?L3Vua29ON21ZT2lOSnJjV01Gb3RIeVhlSUdwa0dqMkFHVk01djZibU1RZndB?=
 =?utf-8?B?cXlHRlIyTERXZnZaYUdUZ1h1aFVPVjNpclhxU3JML0lwRXdhcXQwWnRmblJh?=
 =?utf-8?B?NEo5dmtxb1BJZzNET0JYT2pzcjVsbkZoZzEvbnl3T0thWjE1dlRhS05oSnUz?=
 =?utf-8?B?U1JFYmtxWmtuWG0zZjJBVk1iWGpndVF0NjdwWWc4RGFjRWNZUU00NEhKb2Qv?=
 =?utf-8?B?Mmw2cVRTYXpMdGVtbStRR21LNkRETTVtWGpyRjVZd1V2K1pRdlgwVFdsV1FY?=
 =?utf-8?B?bDVYSE4vR1c3eU1TV1dIZXpHL3E4SzVNWGMzbEtvV3JBbit2L2l1NzllN2ZF?=
 =?utf-8?B?R2hMQ1lqSUdZZU5uclRaS09lbUd4aFFxdzN0bkNSSjZ2N0pReFBGN1J0eWM0?=
 =?utf-8?B?RFhYVHI0M3kvT2diRGIrU1pVL3NNbHZoZ2R6OHc1QkhBVFYvZ21meDZjNHFj?=
 =?utf-8?B?QXBNNENKV0JZR0hrSmNnMWtWSVk2WDZvaTJwaTBYeC94dE4yYVY3R1VOSk1H?=
 =?utf-8?B?cmRyR01QVU9iOW1SUU5FU0RwYjhYbnJwcjRPV0NyTUFBRE54dTVhMjBtMVF6?=
 =?utf-8?B?N21yV2Z1ZVpYVXZBakFBMTRSSDgrSUhNakR0RTFpaEoxWDI3VmRVMU1lT2NF?=
 =?utf-8?B?QzI4S2ljaDBxUnphS2U3UksrMU5pQmZPekNlRjhWT3pLclVZclVMSDRXb0lP?=
 =?utf-8?B?YzFwQWpxQjNjOVRJZ1doSEdXVS9OaU03dXBUR3g3aU0zSmh4K1JVVGJSYmhV?=
 =?utf-8?B?dzI0My9CQzE1SjQ2c1RMcW5DYytZc1ZOalBEQmFqdGM3dXhPMFVYb1NoU2Yr?=
 =?utf-8?B?N2c9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: a35b0915-6d42-4407-8693-08dbb5457198
X-MS-Exchange-CrossTenant-AuthSource: SN7PR11MB7540.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Sep 2023 17:10:06.7050
 (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: wzs+6yoDZI9HuUG2ke9rqNh7DJ9A4nrVZAS+8pVZG10POgDs6uHRuefEEmldgJjKE07accVNtj1ZFnKv3P7hR7PTMQVTcdFjL/iH3eiYK04=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR11MB5762
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Thu, 14 Sep 2023 10:10:24 -0700 (PDT)
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email

On Thu, Sep 14, 2023 at 10:05:47AM -0700, Stanislav Fomichev wrote:
> On Thu, Sep 14, 2023 at 9:55 AM Larysa Zaremba <larysa.zaremba@intel.com> wrote:
> >
> > On Thu, Sep 14, 2023 at 09:29:57AM -0700, Stanislav Fomichev wrote:
> > > On 09/14, Larysa Zaremba wrote:
> > > > There is no fundamental reason, why multi-buffer XDP and XDP kfunc RX hints
> > > > cannot coexist in a single program.
> > > >
> > > > Allow those features to be used together by modifying the flags conditions.
> > > >
> > > > Suggested-by: Stanislav Fomichev <sdf@google.com>
> > > > Link: https://lore.kernel.org/bpf/CAKH8qBuzgtJj=OKMdsxEkyML36VsAuZpcrsXcyqjdKXSJCBq=Q@mail.gmail.com/
> > > > Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> > > > ---
> > > >  kernel/bpf/offload.c | 6 +++++-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/bpf/offload.c b/kernel/bpf/offload.c
> > > > index ee35f33a96d1..43aded96c79b 100644
> > > > --- a/kernel/bpf/offload.c
> > > > +++ b/kernel/bpf/offload.c
> > > > @@ -232,7 +232,11 @@ int bpf_prog_dev_bound_init(struct bpf_prog *prog, union bpf_attr *attr)
> > > >         attr->prog_type != BPF_PROG_TYPE_XDP)
> > > >             return -EINVAL;
> > > >
> > > > -   if (attr->prog_flags & ~BPF_F_XDP_DEV_BOUND_ONLY)
> > > > +   if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS))
> > > > +           return -EINVAL;
> > > > +
> > >
> > > [..]
> > >
> > > > +   if (attr->prog_flags & BPF_F_XDP_HAS_FRAGS &&
> > > > +       !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY))
> > > >             return -EINVAL;
> > >
> > > Any reason we have 'attr->prog_flags & BPF_F_XDP_HAS_FRAGS' part here?
> > > Seems like doing '!(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY)' should
> > > be enough, right? We only want to bail out here when BPF_F_XDP_DEV_BOUND_ONLY
> > > is not set and we don't really care whether BPF_F_XDP_HAS_FRAGS is set
> > > or not at this point.
> >
> > If !(attr->prog_flags & BPF_F_XDP_DEV_BOUND_ONLY) at this point, program could
> > be requesting offload.
> >
> > Now I have thought about those conditions once more and they could be reduced to
> > this:
> >
> > if (attr->prog_flags & ~(BPF_F_XDP_DEV_BOUND_ONLY) &&
> >     attr->prog_flags != (BPF_F_XDP_DEV_BOUND_ONLY | BPF_F_XDP_HAS_FRAGS))
> >         return -EINVAL;
> >
> > What do you think?
> 
> Ah, so this check is here to protect against the mbuf+offloaded
> combination? (looking at that other thread with Maciej)
> Let's keep your current way with two separate checks, but let's add
> your "/* Frags are allowed only if program is dev-bound-only, but not
> if it is requesting
> bpf offload. */" as a comment to the second check?

Ok, sound good to me.