On 2/4/21 2:06 PM, Marcelo Tosatti wrote: > On Thu, Feb 04, 2021 at 01:47:38PM -0500, Nitesh Narayan Lal wrote: [...] >>>>> Nitesh, is there anything preventing this from being fixed >>>>> in userspace ? (as Thomas suggested previously). >>>> Everything with is not managed can be steered by user space. >>> Yes, but it seems to be racy (that is, there is a window where the >>> interrupt can be delivered to an isolated CPU). >>> >>> ethtool -> >>> xgbe_set_channels -> >>> xgbe_full_restart_dev -> >>> xgbe_alloc_memory -> >>> xgbe_alloc_channels -> >>> cpumask_local_spread >>> >>> Also ifconfig eth0 down / ifconfig eth0 up leads >>> to cpumask_spread_local. >> There's always that possibility. > Then there is a window where isolation can be broken. > >> We have to ensure that we move the IRQs by a tuned daemon or some other >> userspace script every time there is a net-dev change (eg. device comes up, >> creates VFs, etc). > Again, race window open can result in interrupt to isolated CPU. Yes, and if I am not mistaken then that always has been a problem with these userspace solutions. > >>> How about adding a new flag for isolcpus instead? >>> >> Do you mean a flag based on which we can switch the affinity mask to >> housekeeping for all the devices at the time of IRQ distribution? > Yes a new flag for isolcpus. HK_FLAG_IRQ_SPREAD or some better name. > > Does sounds like a nice idea to explore, lets see what Thomas thinks about it. -- Thanks Nitesh