On Mon, Oct 21, 2019 at 02:45:05PM +0100, Varghese, Vipin wrote:
> Hi Bruce,
> 
> snipped
> > >  This ability to have the driver pin the interrupts for the
> > > > user would be a big timesaver for developers too, who may be
> > > > constantly re- running apps when testing.
> > > Here my understanding, user can not or should not pass DPDK cores for
> > interrupt pinning. So should we ask the driver to fetch 
> > `rte_eal_configuration`
> > and ensure the same?
> > >
> > 
> > Actually I disagree. I think the user should pass the cores for interrupt 
> > pinning,
> I agree to this.
> 
> > because unlike other PMDs it is perfectly valid to have the interrupts 
> > pinned to
> > dedicated cores separate from those used by DPDK.
> My point is the same, but not on DPDK DP or service cores.
> 
> > 
> > Or taking another example, suppose the app takes 8 cores in the coremask, 
> > but
> > only one of those cores is to be used for I/O, what cores should the driver 
> > pin
> > the interrupts to?
> It can be cores on machine (guest or host) which is not used by DPDK.
> 
>  It probably should be the same core used for I/O, but the
> > driver can't know which cores will be for that, or alternatively the user 
> > might
> > want to use AF_XDP split across two cores, in which case any core on the
> > system might be the intended one for interrupts.
> I agree to the patch, only difference in dev->probe function, should not 
> there be validation to ensure the IRQ core is not DPDK core or Service core 
> as the Interface is owned by kernel and for non matched eBPF skb buff is used 
> by kernel.
> 
No. Since the 5.4 kernel, it's a usable configuration to run both the
kernel and userspace portions of AF_XDP on the same core. In order to get
best performance with a fixed number of cores, this setup - with interrupts
pinned to the polling RX core - is now recommended. [For absolute best perf
using any number of cores, a separate interrupt core may still work best,
though]

/Bruce

Reply via email to