Thanks for the follow up. Understood. That makes sense. However, I’d like to highlight that applications should ideally be robust and interactive enough to handle all edge cases where a segfault or unexpected error might occur. While clear documentation is certainly important, relying solely on it may not be sufficient. In my view, potential segfaults should be handled explicitly in code to ensure stability and to prevent silent failures, especially in production environments. On Tue, Jul 22, 2025, 20:42 Stephen Hemminger wrote: > On Tue, 22 Jul 2025 19:30:41 +0500 > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > Hi Stephen, > > Can we add only the check that fixes the segfault, or do you mean that it > > should be fixed at the PMD level? > > > > Best regards, > > Khadem > > > > On Tue, Jul 22, 2025, 18:39 Stephen Hemminger < > stephen@networkplumber.org> > > wrote: > > > > > On Tue, 22 Jul 2025 07:54:39 -0400 > > > Khadem Ullah <14pwcse1224@uetpeshawar.edu.pk> wrote: > > > > > > > + if (rte_eal_process_type() == RTE_PROC_SECONDARY && > > > > + (dev == NULL || dev->data == NULL || > > > > + dev->data->dev_private == NULL || > > > > > > dev can't be NULL and checking it here will cause a Coverity warning. > > > > > > There are many other ethdev calls that will fail if primary dies. > > > stats, xstats, rx/tx burst, ... > > > > > > I don't think it is good idea to add checks here. > > > > > It needs to be fixed at the documentation level. > Make sure and document what applications need to do. Rather than adding > more checks in ethdev. >