On 10/2/19 11:37 PM, Ido Schimmel wrote: >>>>> The new indication is dumped to user space via a new flag (i.e., >>>>> 'RTM_F_IN_HW') in the 'rtm_flags' field in the ancillary header. >>>>> >>>> >>>> nice series Ido. why not call this RTM_F_OFFLOAD to keep it consistent >>>> with the nexthop offload indication ?. >>> >>> See the second paragraph of this description. >> >> I read it multiple times. It does not explain why RTM_F_OFFLOAD is not >> used. Unless there is good reason RTM_F_OFFLOAD should be the name for >> consistency with all of the other OFFLOAD flags. > > David, I'm not sure I understand the issue. You want the flag to be > called "RTM_F_OFFLOAD" to be consistent with "RTNH_F_OFFLOAD"? Are you > OK with iproute2 displaying it as "in_hw"? Displaying it as "offload" is > really wrong for the reasons I mentioned above. Host routes (for > example) do not offload anything from the kernel, they just reside in > hardware and trap packets... > > The above is at least consistent with tc where we already have > "TCA_CLS_FLAGS_IN_HW". > >> I realize rtm_flags is overloaded and the lower 8 bits contains RTNH_F >> flags, but that can be managed with good documentation - that RTNH_F >> is for the nexthop and RTM_F is for the prefix. > > Are you talking about documenting the display strings in "ip-route" man > page or something else? If we stick with "offload" and "in_hw" then they > should probably be documented there to avoid confusion. >
Sounds like there are 2 cases for prefixes that should be flagged to the user -- "offloaded" (as in traffic is offloaded) and "in_hw" (prefix is in hardware but forwarding is not offloaded).
