On Thu, 28 Jan 2021 20:33:22 -0700 David Ahern wrote: > On 1/28/21 8:04 PM, Jakub Kicinski wrote: > > On Tue, 26 Jan 2021 15:23:06 +0200 Ido Schimmel wrote: > >> Emit RTM_NEWROUTE notifications whenever RTM_F_OFFLOAD/RTM_F_TRAP flags > >> are changed. The aim is to provide an indication to user-space > >> (e.g., routing daemons) about the state of the route in hardware. > > > > What does the daemon in the user space do with it? > > You don't want FRR for example to advertise a route to a peer until it > is really programmed in h/w. This notification gives routing daemons > that information.
I see. Hm. > > The notification will only be generated for the _first_ ASIC which > > offloaded the object. Which may be fine for you today but as an uAPI > > it feels slightly lacking. > > > > If the user space just wants to make sure the devices are synced to > > notifications from certain stage, wouldn't it be more idiomatic to > > provide some "fence" operation? > > > > WDYT? David? > > This feature was first discussed I think about 2 years ago - when I was > still with Cumulus, so I already knew the intent and end goal. > > I think support for multiple ASICs / NICs doing this kind of offload > will have a whole lot of challenges. I don't think this particular user > notification is going to be a big problem - e.g., you could always delay > the emit until all have indicated the offload. My impression from working on this problem in TC is that the definition of "all" becomes problematic especially if one takes into account drivers getting reloaded. But I think routing offload has stronger semantics than TC, so no objections. We need a respin for the somewhat embarrassing loop in patch 1, tho.
