On 2024/9/14 10:54, Stephen Hemminger wrote: > On Fri, 13 Sep 2024 10:55:08 +0800 > "WanRenyong" <wa...@yunsilicon.com> wrote: > >>> >>>> 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? >>> It seemed the ioctl couldn't handle VF located in VM, and interact >>> with PF driver which run in host kernel. >>>> If not, could you please give me some advice? >>> If your NIC support firmware, could consider use firmware as mid-man >>> between DPDK and kernel. >>> >>>> >> Hello, fengchenwen, >> >> Thanks for your reply. >> Sorry for not describing it clearly. We know how to implement the >> bifurcation functionality. The main issue is that ioctl is used >> forcommunication with the kernel driver by PMD, but ioctl is not >> considered a good API, we need to find a better approach. Implemented >> via firmware might be a good idea, but it's complex, we can think about >> it in the further.Recently shoud I consider using read and write >> instead? 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 still > exists) > 3. BPF > > It seems unlikely a new approach using ioctl() that only works on your device > would be accepted by the netdev developers.
I just "grep -rn ioctl | wc -l" and found there are 518. Some of them are net driver which open char device. Ioctl could be an option as long as it meets current and future needs.
