On 10/4/19 11:43 AM, Roopa Prabhu wrote:
> On Fri, Oct 4, 2019 at 9:38 AM David Ahern 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
>>>
On Fri, Oct 4, 2019 at 9:38 AM David Ahern 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
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?
>
> R
On Thu, Oct 03, 2019 at 07:55:16PM -0600, David Ahern wrote:
> 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 ca
On Thu, Oct 3, 2019 at 5:59 AM Ido Schimmel wrote:
>
> On Wed, Oct 02, 2019 at 08:58:52AM -0700, Roopa Prabhu wrote:
> > On Wed, Oct 2, 2019 at 1:41 AM Ido Schimmel wrote:
> > >
> > > From: Ido Schimmel
> > >
> > > When performing L3 offload, routes and nexthops are usually programmed
> > > into
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
On Wed, Oct 02, 2019 at 08:58:52AM -0700, Roopa Prabhu wrote:
> On Wed, Oct 2, 2019 at 1:41 AM Ido Schimmel wrote:
> >
> > From: Ido Schimmel
> >
> > When performing L3 offload, routes and nexthops are usually programmed
> > into two different tables in the underlying device. Therefore, the fact
Thu, Oct 03, 2019 at 04:34:22AM CEST, dsah...@gmail.com wrote:
>On 10/2/19 12:21 PM, Jiri Pirko wrote:
This patch adds an "in hardware" indication to IPv4 routes, so that
users will have better visibility into the offload process. In the
future IPv6 will be extended with this indicat
On Wed, Oct 02, 2019 at 08:34:22PM -0600, David Ahern wrote:
> On 10/2/19 12:21 PM, Jiri Pirko wrote:
> >>> This patch adds an "in hardware" indication to IPv4 routes, so that
> >>> users will have better visibility into the offload process. In the
> >>> future IPv6 will be extended with this indic
On 10/2/19 12:21 PM, Jiri Pirko wrote:
>>> This patch adds an "in hardware" indication to IPv4 routes, so that
>>> users will have better visibility into the offload process. In the
>>> future IPv6 will be extended with this indication as well.
>>>
>>> 'struct fib_alias' is extended with a new fiel
Wed, Oct 02, 2019 at 05:58:52PM CEST, ro...@cumulusnetworks.com wrote:
>On Wed, Oct 2, 2019 at 1:41 AM Ido Schimmel wrote:
>>
>> From: Ido Schimmel
>>
>> When performing L3 offload, routes and nexthops are usually programmed
>> into two different tables in the underlying device. Therefore, the fa
On Wed, Oct 2, 2019 at 1:41 AM Ido Schimmel wrote:
>
> From: Ido Schimmel
>
> When performing L3 offload, routes and nexthops are usually programmed
> into two different tables in the underlying device. Therefore, the fact
> that a nexthop resides in hardware does not necessarily mean that all
>
From: Ido Schimmel
When performing L3 offload, routes and nexthops are usually programmed
into two different tables in the underlying device. Therefore, the fact
that a nexthop resides in hardware does not necessarily mean that all
the associated routes also reside in hardware and vice-versa.
Wh
13 matches
Mail list logo
