From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: David Ahern <dsahern@gmail.com>
Cc: David Miller <davem@davemloft.net>,
netdev@vger.kernel.org, edumazet@google.com, kafai@fb.com
Subject: Re: [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file
Date: Mon, 25 Mar 2019 20:05:39 -0700 [thread overview]
Message-ID: <20190326030536.kjzp2redp33y7hk6@ast-mbp> (raw)
In-Reply-To: <61520dad-939f-46ff-626b-dea91b845aa3@gmail.com>
On Mon, Mar 25, 2019 at 11:02:07AM -0600, David Ahern wrote:
>
> That is followed by refactoring IPv6 again in a direction that makes
> IPv4 and IPv6 more consistent and enables changes (outside of the
> nexthop sets) that will improve IPv6 for a number of cases by removing
> the need to always generate a dst_entry.
That would be a nice feature to have.
> After that are a few patches exporting functions for use by nexthop code
> and then diving into the refactoring enabling separate nexthop objects.
> Again, impacts to performance have been top of mind, and I have done
> what I can to minimize any overhead in the datapath - to the point of a
> few ‘if (nh)’ checks wrapped in an unlikely. And with the nexthop code
> in place it gives users an alternative to a broken IPv6 multipath API as
> one example.
...
> Again, I have tried to be very careful with the intrusion of checks into
> the datapath with the goal of no measurable impact to performance. I am
> invested to seeing that through and will continue looking for ways to
> improve it for all use cases.
Great to hear.
Can you split up your set into reviewable chunks?
Just this patch alone is too small to see the road ahead
and 80+ patches are too much to review properly.
I still have reservations regarding nexthop id concept, but sounds like
the first 20 or so patches should clean things up.
Especially if you can get rid of dst alloc/free back and forth in ipv6 case.
next prev parent reply other threads:[~2019-03-26 3:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 13:06 [PATCH net-next] ipv6: Move ipv6 stubs to a separate header file David Ahern
2019-03-22 16:14 ` Alexei Starovoitov
2019-03-22 16:17 ` David Ahern
2019-03-22 17:04 ` Alexei Starovoitov
2019-03-24 1:40 ` David Miller
2019-03-24 3:55 ` Alexei Starovoitov
2019-03-24 12:56 ` David Ahern
2019-03-25 3:26 ` Alexei Starovoitov
2019-03-25 15:39 ` Stephen Suryaputra
2019-03-25 17:02 ` David Ahern
2019-03-26 3:05 ` Alexei Starovoitov [this message]
2019-03-26 14:19 ` David Ahern
2019-03-26 15:11 ` Alexei Starovoitov
2019-03-26 15:29 ` David Ahern
2019-03-26 2:22 ` David Ahern
2019-03-29 17:55 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190326030536.kjzp2redp33y7hk6@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=davem@davemloft.net \
--cc=dsahern@gmail.com \
--cc=edumazet@google.com \
--cc=kafai@fb.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox