netdev - Re: [RFC PATCH net-next 12/15] ipv4: Add "in hardware" indication to routes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e4f0dbf6-2852-c658-667b-65374e73a27d@gmail.com>
Date:   Thu, 3 Oct 2019 19:55:16 -0600
From:   David Ahern <dsahern@...il.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     Jiri Pirko <jiri@...nulli.us>,
        Roopa Prabhu <roopa@...ulusnetworks.com>,
        netdev <netdev@...r.kernel.org>,
        David Miller <davem@...emloft.net>,
        Jiri Pirko <jiri@...lanox.com>,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        Saeed Mahameed <saeedm@...lanox.com>,
        mlxsw <mlxsw@...lanox.com>, Ido Schimmel <idosch@...lanox.com>
Subject: Re: [RFC PATCH net-next 12/15] ipv4: Add "in hardware" indication to
 routes

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).