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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJieiUivWMD_QkqYA6Y08Ru3hCoy==MGaiNq7ma2K06WxgFuRg@mail.gmail.com>
Date:   Fri, 4 Oct 2019 10:43:17 -0700
From:   Roopa Prabhu <roopa@...ulusnetworks.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Ido Schimmel <idosch@...sch.org>, Jiri Pirko <jiri@...nulli.us>,
        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 Fri, Oct 4, 2019 at 9:38 AM David Ahern <dsahern@...il.com> wrote:
>
> On 10/4/19 8:43 AM, Ido Schimmel wrote:
> >> 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).
> > Sounds good. Are you and Roopa OK with the below?
> >
> > RTM_F_IN_HW - route is in hardware
> > RTM_F_OFFLOAD - route is offloaded
> >
> > For example, host routes will have the first flag set, whereas prefix
> > routes will have both flags set.
>
> if "offload" always includes "in_hw", then are both needed? ie., why not
> document that offload means in hardware with offloaded traffic, and then
> "in_hw" is a lesser meaning - only in hardware with a trap to CPU?

I was wondering if we can just call these RTM_F_OFFLOAD_TRAP or
RTM_F_OFFLOAD_ASSIT or something along those lines.

My only concern with the proposed names is, both mean HW offload but
only one uses HW in the name which can be confusing down the lane :).



>
> >
> > Together with the existing offload flags for nexthops and neighbours
> > this provides great visibility into the entire offload process.
>