From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C738945985; Sat, 14 Sep 2024 04:54:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A0A8E4026C; Sat, 14 Sep 2024 04:54:33 +0200 (CEST) Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by mails.dpdk.org (Postfix) with ESMTP id F03B54026A for ; Sat, 14 Sep 2024 04:54:32 +0200 (CEST) Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-2053a0bd0a6so28499625ad.3 for ; Fri, 13 Sep 2024 19:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1726282472; x=1726887272; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=3jpKN+GOegVWzOI1k5qktikeEe9RRDAFLoiqzeI0+mk=; b=draiJr/LfDXDj7ZlK4/xffV0qA7UGmbpIk4CIpMEbxu7WRtyhm3YXQyAIfpfdAwT6f 5lVDxWA+3I6yX5Wr0AThg9yw9bCcP967O+EpS5fHwluLb8/qX6xo6YBGU9LGFXr+ZyDO a3LrUPgMF7mKQ+2Z37ADx2PcPrRCrOC2amAvNjIzgeivrG3SM3A6GV4zY0X9vLsMtlQD YAAipKlObpCCXw9/eaeq70OZEVgV4EE+l4LCuN2eCt0XeuYCUH82hxQQin+c7vW+42Dg uNqB2BiMyA2fWd1461IaxFJ0f1pO1Wbs45x+E9gRBjz/4xNWhF1REx/2nMjio5LbblrO QMLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726282472; x=1726887272; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3jpKN+GOegVWzOI1k5qktikeEe9RRDAFLoiqzeI0+mk=; b=k7ouEOQTg9NmuKaKpIGtgzC2h9KKeALdugb6ktUJ21uyLWH8tIZ8yRAwydPttY4QB6 dGk1F//6hGiHoAHHIkTS17qB7Gn1nJ/1dxGrgC/GsCILKzb7K9Lr6lfTHyvCC6jDanRm VikuGeXVnblfO7Jhb0RpR1223fEwvYJjnqGc/qSuM1hTleBsT7f/xc+qy++zu1aCiQu1 obhXwWilkwuVSBBVaJDA7iefosEvG+U+L1I+MNzjSMkghpjoR2/VJkadj/gtvUUiE5nX 4dnaIKG5ti8DqaeZHwCyjWLiBO90xbRdLcjNcr7bmjF5cswK+ZT//T8GWJDPYD5PkwET C/Pw== X-Forwarded-Encrypted: i=1; AJvYcCVyIeGLcPmXFeRaKxfCp8i8OBkziaP0JXvJkS20/WFCPJlm8lHnucFkbjDIY9ORTe7W/Us=@dpdk.org X-Gm-Message-State: AOJu0Yyv6o6LSx3yoZ1Y/HCxBNnr39SBz1WJwF0WKgXKi+bagpA6J2ko eCZsqpj+FLdESYCU9fR6uWKiRmOBJOQEzTbuNplZvS2BB/kG/pjKD5Bomxn/nN0= X-Google-Smtp-Source: AGHT+IFE3vZoPZw2QGMumRbly/nhGFpmr+73yYI0vsBkiTcVp1xqbprEbkl68D7IssgwzI45oZaqSw== X-Received: by 2002:a17:902:cf04:b0:207:44b0:e6bd with SMTP id d9443c01a7336-2076e44b9b1mr146144915ad.57.1726282471786; Fri, 13 Sep 2024 19:54:31 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-20794601379sm2648775ad.95.2024.09.13.19.54.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Sep 2024 19:54:31 -0700 (PDT) Date: Fri, 13 Sep 2024 19:54:29 -0700 From: Stephen Hemminger To: "WanRenyong" Cc: "fengchengwen" , , , Subject: Re: [PATCH v2 05/19] net/xsc: add ioctl command interface Message-ID: <20240913195429.1e6f174b@hermes.local> In-Reply-To: References: <20240911020740.3950704-6-wanry@yunsilicon.com> <20240910205058.25bf5f8c@hermes.local> <8cf9b5e8-cab4-45e6-b959-1d87f8a8ea99@yunsilicon.com> <20240911225021.16839cb2@hermes.local> <1ff7f17e-181b-49da-8f84-bf430f449dec@yunsilicon.com> <7c5d74b1-2d69-4595-b966-4044b6f7c698@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 13 Sep 2024 10:55:08 +0800 "WanRenyong" wrote: > > =20 > >> Ioctl API is used for interaction between PMD and kernel driver. As you > >> said, ioctl is > >> > >> the worst API, should I consider using read and write instead? =20 > > It seemed the ioctl couldn't handle VF located in VM, and interact=20 > > with PF driver which run in host kernel. =20 > >> If not, could you please give me some advice? =20 > > If your NIC support firmware, could consider use firmware as mid-man be= tween DPDK and kernel. > > =20 > >> =20 > Hello, fengchenwen, >=20 > Thanks for your reply. > Sorry for not describing it clearly. We know how to implement the=20 > bifurcation functionality. The main issue is that ioctl is used=20 > forcommunication with the kernel driver by PMD, but ioctl is not=20 > considered a good API, we need to find a better approach. Implemented=20 > via firmware might be a good idea, but it's complex, we can think about=20 > it in the further.Recently shoud I consider using read and write=20 > instead?=C2=A0 Is there any advise? There are already several pre-existing ways to do bifurcation in drivers. 1. RDMA which is used by mlx5 and mana drivers. 2. using SR-IOV and queue steering. (Intel did this but not sure if it stil= l exists) 3. BPF It seems unlikely a new approach using ioctl() that only works on your devi= ce would be accepted by the netdev developers.