From: Andy Gospodarek <gospo@cumulusnetworks.com>
To: sfeldma@gmail.com
Cc: netdev@vger.kernel.org, stephen@networkplumber.org,
jiri@resnulli.us, roopa@cumulusnetworks.com, tarbal@gmail.com,
linville@tuxdriver.com
Subject: Re: [PATCH iproute2 v2] route: label externally offloaded routes
Date: Mon, 16 Mar 2015 09:18:05 -0400 [thread overview]
Message-ID: <20150316131805.GF12614@gospo.home.greyhouse.net> (raw)
In-Reply-To: <1426447894-41398-1-git-send-email-sfeldma@gmail.com>
On Sun, Mar 15, 2015 at 12:31:34PM -0700, sfeldma@gmail.com wrote:
> From: Scott Feldman <sfeldma@gmail.com>
>
> v2:
>
> No clear outcome on polling for choices of "external", "offload", "hw", or
> "hardware". Andy's concern about "external" being confusing for users is
> valid. So, I'm making executive decision to use "external_offload" for label,
> as suggested by Jiri.
This seems like quite a mouthful. Just make it 'offload' or 'hardware'
so the output of 'ip route show' isn't so long that it will frequently
be longer than 80 chars. Being longer than 80 chars is going to be
irritating for _many_ users.
>
> v1:
>
> On ip route print dump, label externally offloaded routes with "external".
> Offloaded routes are flagged with RTNH_F_EXTERNAL, a recent additon to
> net-next. For example:
>
> $ ip route
> default via 192.168.0.2 dev eth0
> 11.0.0.0/30 dev swp1 proto kernel scope link src 11.0.0.2 external
> 11.0.0.4/30 via 11.0.0.1 dev swp1 proto zebra metric 20 external
> 11.0.0.8/30 dev swp2 proto kernel scope link src 11.0.0.10 external
> 11.0.0.12/30 via 11.0.0.9 dev swp2 proto zebra metric 20 external
> 12.0.0.2 proto zebra metric 30 external
> nexthop via 11.0.0.1 dev swp1 weight 1
> nexthop via 11.0.0.9 dev swp2 weight 1
> 12.0.0.3 via 11.0.0.1 dev swp1 proto zebra metric 20 external
> 12.0.0.4 via 11.0.0.9 dev swp2 proto zebra metric 20 external
> 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.15
I understand why you did this the way you did (keeping the changelog the
same with the only change being the parts listed in 'v2'), but could you
change the new output to reflect the code change? Readers of the git
log would probably be confused by this.
(Sorry to debate such a simple patch, but this is the interface most will
use so it seems like a good idea to make sure we are thinking about it
in the proper context. Healthy debate on the mailing-list seems like a
great way to track the reason behind some of these decisions.)
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
> Acked-by: Jiri Pirko <jiri@resnulli.us>
> ---
> include/linux/rtnetlink.h | 1 +
> ip/iproute.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
> index 3eb7810..c74773c 100644
> --- a/include/linux/rtnetlink.h
> +++ b/include/linux/rtnetlink.h
> @@ -332,6 +332,7 @@ struct rtnexthop {
> #define RTNH_F_DEAD 1 /* Nexthop is dead (used by multipath) */
> #define RTNH_F_PERVASIVE 2 /* Do recursive gateway lookup */
> #define RTNH_F_ONLINK 4 /* Gateway is forced on link */
> +#define RTNH_F_EXTERNAL 8 /* Route installed externally */
>
> /* Macros to handle hexthops */
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index b32025f..ffdf4f2 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -412,6 +412,8 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
> fprintf(fp, "onlink ");
> if (r->rtm_flags & RTNH_F_PERVASIVE)
> fprintf(fp, "pervasive ");
> + if (r->rtm_flags & RTNH_F_EXTERNAL)
> + fprintf(fp, "external_offload ");
> if (r->rtm_flags & RTM_F_NOTIFY)
> fprintf(fp, "notify ");
> if (tb[RTA_MARK]) {
> --
> 1.7.10.4
>
next prev parent reply other threads:[~2015-03-16 13:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-15 19:31 [PATCH iproute2 v2] route: label externally offloaded routes sfeldma
2015-03-16 13:18 ` Andy Gospodarek [this message]
2015-03-16 13:46 ` roopa
2015-03-17 4:14 ` Scott Feldman
2015-03-17 7:01 ` Jiri Pirko
2015-03-17 13:24 ` Andy Gospodarek
2015-03-17 13:49 ` Jiri Pirko
2015-03-17 19:15 ` Andy Gospodarek
2015-03-24 22:51 ` Stephen Hemminger
2015-03-25 0:33 ` Andy Gospodarek
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=20150316131805.GF12614@gospo.home.greyhouse.net \
--to=gospo@cumulusnetworks.com \
--cc=jiri@resnulli.us \
--cc=linville@tuxdriver.com \
--cc=netdev@vger.kernel.org \
--cc=roopa@cumulusnetworks.com \
--cc=sfeldma@gmail.com \
--cc=stephen@networkplumber.org \
--cc=tarbal@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.