On 2024/9/12 17:18, fengchengwen wrote: > On 2024/9/12 16:19, WanRenyong wrote: >> On 2024/9/12 13:50, Stephen Hemminger wrote: >>> On Thu, 12 Sep 2024 12:14:08 +0800 >>> "WanRenyong" <wa...@yunsilicon.com> wrote: >>> >>>>> >>>>>> +}; >>>>>> + >>>>> Does this device driver depend on some upstr >>>> Yes, it depends on linux kernel driver of the device. >>>> >>>> Hello, Stephen, >>>> >>>> Thanks for your review, please see above. >>> What is the driver? I don't see in the current kernel.org tree. >>> >>> >>> My concern is that if the driver is not upstream, it is probably not >>> going to pass the review of kernel developers. This means security and >>> API changes would be required. >>> >>> Ioctl's are considered the worst API to the kernel and unlikely >>> to be accepted. >> Hello, Stephen, >> >> Thank you for reply.Our kernel driver is being prepared to open source. >> >> Our PMD is going to coexist with kernel driver to support flow >> bifurcation feature. > It seemed uacce bus could handle this, so that you could use several queues > on DPDK, and > steer flows to these queues by bifurcation feature. > >> 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? -- Thanks, WanRenyong
