[dpdk-dev] drops while transmitting to the kni using rte_kni_tx_burst()

Jason Kwon m43kwon at gmail.com
Fri Jan 20 20:48:02 CET 2017


Sorry to hijack the thread, but I was wondering, is the binding of the KNI
kernel thread only applicable in multiple kthread mode?  Does it apply in
single kernel thread mode?  Looking at the 16.07.2 source, I saw the
following:

        /**
         * Create a new kernel thread for multiple mode, set its core
affinity,
         * and finally wake it up.
         */
        if (multiple_kthread_on) {
                kni->pthread = kthread_create(kni_thread_multiple,
                                              (void *)kni,
                                              "kni_%s", kni->name);
                if (IS_ERR(kni->pthread)) {
                        kni_dev_remove(kni);
                        return -ECANCELED;
                }
                if (dev_info.force_bind)
                        kthread_bind(kni->pthread, kni->core_id);
                wake_up_process(kni->pthread);
        }

Thanks,

Jason

On Mon, Jan 16, 2017 at 6:42 AM, Ferruh Yigit <ferruh.yigit at intel.com>
wrote:

> On 1/16/2017 12:20 PM, Shirley Avishour wrote:
> > Hi,
> > I have an application over dpdk which is consisted of the following
> threads
> > each running on a separate core:
> > 1) rx thread which listens on in a poll mode for traffic
> > 2) 2 packet processing threads (for load balancing)
> > 3) kni thread (which also runs on a separate core).
>
> This is kernel thread, right? Is it bind to any specific core?
> Is it possible that this thread shares the core with 2nd processing
> thread when enabled?
>
> >
> > the rx thread receives packets and clones them and transmit a copy to the
> > kni and the other packet is sent to the packet processing unit (hashing
> > over 2 threads).
> > the receive traffic rate is 100Mbps.
> > When working with single packet processing thread I am able to get all
> the
> > 100Mbps towards the kni with no drops.
> > but when I activate my application with 2 packet processing threads I
> start
> > facing drops towards the kni.
> > the way I see it the only difference now is that I have another threads
> > which handles an mbuf and frees it once processing is completed.
> > Can anyone assist with this case please?
> >
> > Thanks!
> >
>
>


More information about the dev mailing list