All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] iproute: Add support for extended ack to rtnl_talk
@ 2017-05-03 23:56 Stephen Hemminger
  2017-05-04  9:36 ` Daniel Borkmann
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-03 23:56 UTC (permalink / raw)
  To: netdev; +Cc: Stephen Hemminger

Add support for extended ack error reporting via libmnl. This
is a better alternative to use existing library and not copy/paste
code from the kernel. Also make arguments const where possible.

Add a new function rtnl_talk_extack that takes a callback as an input
arg. If a netlink response contains extack attributes, the callback is
is invoked with the the err string, offset in the message and a pointer
to the message returned by the kernel.

Adding a new function allows commands to be moved over to the
extended error reporting over time.

For feedback, compile tested only.

---
 include/libnetlink.h |   6 +++
 lib/Makefile         |   7 ++++
 lib/libnetlink.c     | 110 +++++++++++++++++++++++++++++++++++++++++++++++----
 3 files changed, 116 insertions(+), 7 deletions(-)

diff --git a/include/libnetlink.h b/include/libnetlink.h
index c43ab0a2d9d9..32d5177cd1ab 100644
--- a/include/libnetlink.h
+++ b/include/libnetlink.h
@@ -66,6 +66,9 @@ typedef int (*rtnl_listen_filter_t)(const struct sockaddr_nl *,
 				    struct rtnl_ctrl_data *,
 				    struct nlmsghdr *n, void *);
 
+typedef int (*nl_ext_ack_fn_t)(const char *errmsg, uint32_t off,
+			       const struct nlmsghdr *inner_nlh);
+
 struct rtnl_dump_filter_arg {
 	rtnl_filter_t filter;
 	void *arg1;
@@ -82,6 +85,9 @@ int rtnl_dump_filter_nc(struct rtnl_handle *rth,
 int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 	      struct nlmsghdr *answer, size_t len)
 	__attribute__((warn_unused_result));
+int rtnl_talk_extack(struct rtnl_handle *rtnl, struct nlmsghdr *n,
+	      struct nlmsghdr *answer, size_t len, nl_ext_ack_fn_t errfn)
+	__attribute__((warn_unused_result));
 int rtnl_talk_suppress_rtnl_errmsg(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 				   struct nlmsghdr *answer, size_t len)
 	__attribute__((warn_unused_result));
diff --git a/lib/Makefile b/lib/Makefile
index 1d24ca24b9a3..f81888cca974 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -4,6 +4,13 @@ ifeq ($(IP_CONFIG_SETNS),y)
 	CFLAGS += -DHAVE_SETNS
 endif
 
+ifeq ($(HAVE_MNL),y)
+	CFLAGS += $(shell $(PKG_CONFIG) libmnl --cflags)
+	LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
+else
+@warn "libmnl required for error support"
+endif
+
 CFLAGS += -fPIC
 
 UTILOBJ = utils.o rt_names.o ll_types.o ll_proto.o ll_addr.o \
diff --git a/lib/libnetlink.c b/lib/libnetlink.c
index 5b75b2db4e0b..20ec7fe20d7c 100644
--- a/lib/libnetlink.c
+++ b/lib/libnetlink.c
@@ -36,6 +36,79 @@
 
 int rcvbuf = 1024 * 1024;
 
+#ifdef HAVE_LIBMNL
+#include <libmnl/libmnl.h>
+
+static const enum mnl_attr_data_type extack_policy[NLMSGERR_ATTR_MAX + 1] = {
+	[NLMSGERR_ATTR_MSG]	= MNL_TYPE_NUL_STRING,
+	[NLMSGERR_ATTR_OFFS]	= MNL_TYPE_U32,
+};
+
+static int err_attr_cb(const struct nlattr *attr, void *data)
+{
+	const struct nlattr **tb = data;
+	uint16_t type;
+
+	if (mnl_attr_type_valid(attr, NLMSGERR_ATTR_MAX) < 0)
+		return MNL_CB_ERROR;
+
+	type = mnl_attr_get_type(attr);
+	if (mnl_attr_validate(attr, extack_policy[type]) < 0)
+		return MNL_CB_ERROR;
+
+
+	tb[type] = attr;
+	return MNL_CB_OK;
+}
+
+
+/* dump netlink extended ack error message */
+static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
+{
+	struct nlattr *tb[NLMSGERR_ATTR_MAX + 1];
+	const struct nlmsgerr *err = mnl_nlmsg_get_payload(nlh);
+	const struct nlmsghdr *err_nlh = NULL;
+	unsigned int hlen = sizeof(*err);
+	const char *errmsg = NULL;
+	uint32_t off = 0;
+
+	if (!errfn)
+		return 0;
+
+	/* no TLVs, nothing to do here */
+	if (!(nlh->nlmsg_flags & NLM_F_ACK_TLVS))
+		return 0;
+
+	/* if NLM_F_CAPPED is set then the inner err msg was capped */
+	if (!(nlh->nlmsg_flags & NLM_F_CAPPED))
+		hlen += mnl_nlmsg_get_payload_len(&err->msg);
+
+	mnl_attr_parse(nlh, hlen, err_attr_cb, tb);
+
+	if (tb[NLMSGERR_ATTR_MSG])
+		errmsg = mnl_attr_get_str(tb[NLMSGERR_ATTR_MSG]);
+
+	if (tb[NLMSGERR_ATTR_OFFS]) {
+		off = mnl_attr_get_u32(tb[NLMSGERR_ATTR_OFFS]);
+
+		if (off > nlh->nlmsg_len) {
+			fprintf(stderr,
+				"Invalid offset for NLMSGERR_ATTR_OFFS\n");
+			off = 0;
+		} else if (!(nlh->nlmsg_flags & NLM_F_CAPPED))
+			err_nlh = &err->msg;
+	}
+
+	return errfn(errmsg, off, err_nlh);
+}
+#else
+/* No extended error ack without libmnl */
+static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t errfn)
+{
+	return 0;
+}
+#endif
+
 void rtnl_close(struct rtnl_handle *rth)
 {
 	if (rth->fd >= 0) {
@@ -49,6 +122,7 @@ int rtnl_open_byproto(struct rtnl_handle *rth, unsigned int subscriptions,
 {
 	socklen_t addr_len;
 	int sndbuf = 32768;
+	int one = 1;
 
 	memset(rth, 0, sizeof(*rth));
 
@@ -71,6 +145,11 @@ int rtnl_open_byproto(struct rtnl_handle *rth, unsigned int subscriptions,
 		return -1;
 	}
 
+	if (setsockopt(rth->fd, SOL_NETLINK, NETLINK_EXT_ACK,
+		       &one, sizeof(one)) < 0) {
+		/* debug/verbose message that it is not supported */
+	}
+
 	memset(&rth->local, 0, sizeof(rth->local));
 	rth->local.nl_family = AF_NETLINK;
 	rth->local.nl_groups = subscriptions;
@@ -417,9 +496,19 @@ int rtnl_dump_filter_nc(struct rtnl_handle *rth,
 	return rtnl_dump_filter_l(rth, a);
 }
 
+static void rtnl_talk_error(struct nlmsghdr *h, struct nlmsgerr *err,
+			    nl_ext_ack_fn_t errfn)
+{
+	if (nl_dump_ext_err(h, errfn))
+		return;
+
+	fprintf(stderr, "RTNETLINK answers: %s\n",
+		strerror(-err->error));
+}
+
 static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 		       struct nlmsghdr *answer, size_t maxlen,
-		       bool show_rtnl_err)
+		       bool show_rtnl_err, nl_ext_ack_fn_t errfn)
 {
 	int status;
 	unsigned int seq;
@@ -506,10 +595,10 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 					return 0;
 				}
 
-				if (rtnl->proto != NETLINK_SOCK_DIAG && show_rtnl_err)
-					fprintf(stderr,
-						"RTNETLINK answers: %s\n",
-						strerror(-err->error));
+				if (rtnl->proto != NETLINK_SOCK_DIAG &&
+				    show_rtnl_err)
+					rtnl_talk_error(h, err, errfn);
+
 				errno = -err->error;
 				return -1;
 			}
@@ -541,13 +630,20 @@ static int __rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 int rtnl_talk(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 	      struct nlmsghdr *answer, size_t maxlen)
 {
-	return __rtnl_talk(rtnl, n, answer, maxlen, true);
+	return __rtnl_talk(rtnl, n, answer, maxlen, true, NULL);
+}
+
+int rtnl_talk_extack(struct rtnl_handle *rtnl, struct nlmsghdr *n,
+		     struct nlmsghdr *answer, size_t maxlen,
+		     nl_ext_ack_fn_t errfn)
+{
+	return __rtnl_talk(rtnl, n, answer, maxlen, true, errfn);
 }
 
 int rtnl_talk_suppress_rtnl_errmsg(struct rtnl_handle *rtnl, struct nlmsghdr *n,
 				   struct nlmsghdr *answer, size_t maxlen)
 {
-	return __rtnl_talk(rtnl, n, answer, maxlen, false);
+	return __rtnl_talk(rtnl, n, answer, maxlen, false, NULL);
 }
 
 int rtnl_listen_all_nsid(struct rtnl_handle *rth)
-- 
2.11.0

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-03 23:56 [RFC] iproute: Add support for extended ack to rtnl_talk Stephen Hemminger
@ 2017-05-04  9:36 ` Daniel Borkmann
  2017-05-04 14:27   ` David Ahern
                     ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Daniel Borkmann @ 2017-05-04  9:36 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev

On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
> Add support for extended ack error reporting via libmnl. This
> is a better alternative to use existing library and not copy/paste
> code from the kernel. Also make arguments const where possible.
>
> Add a new function rtnl_talk_extack that takes a callback as an input
> arg. If a netlink response contains extack attributes, the callback is
> is invoked with the the err string, offset in the message and a pointer
> to the message returned by the kernel.
>
> Adding a new function allows commands to be moved over to the
> extended error reporting over time.
>
> For feedback, compile tested only.

Just out of curiosity, what is the plan regarding converting iproute2
over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
user merged that requires libmnl, the only other user today in the
tree is devlink, which even seems to define its own libmnl library
helpers. What is the clear benefit/rationale of outsourcing this to
libmnl? I always was the impression we should strive for as little
dependencies as possible?

I don't really like that we make extended ack reporting now dependent
on libmnl, which further diverts from iproute's native nl library vs
requiring to install another nl library, making the current status
quo even worse ... :/

Thanks,
Daniel

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04  9:36 ` Daniel Borkmann
@ 2017-05-04 14:27   ` David Ahern
  2017-05-04 14:41     ` David Miller
  2017-05-04 14:37   ` Leon Romanovsky
  2017-05-04 16:42   ` Stephen Hemminger
  2 siblings, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-05-04 14:27 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Hemminger; +Cc: netdev

On 5/4/17 3:36 AM, Daniel Borkmann wrote:
> What is the clear benefit/rationale of outsourcing this to
> libmnl? I always was the impression we should strive for as little
> dependencies as possible?

+1

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04  9:36 ` Daniel Borkmann
  2017-05-04 14:27   ` David Ahern
@ 2017-05-04 14:37   ` Leon Romanovsky
  2017-05-04 16:45     ` Stephen Hemminger
  2017-05-04 16:42   ` Stephen Hemminger
  2 siblings, 1 reply; 27+ messages in thread
From: Leon Romanovsky @ 2017-05-04 14:37 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: Stephen Hemminger, netdev

[-- Attachment #1: Type: text/plain, Size: 1988 bytes --]

On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann wrote:
> On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
> > Add support for extended ack error reporting via libmnl. This
> > is a better alternative to use existing library and not copy/paste
> > code from the kernel. Also make arguments const where possible.
> >
> > Add a new function rtnl_talk_extack that takes a callback as an input
> > arg. If a netlink response contains extack attributes, the callback is
> > is invoked with the the err string, offset in the message and a pointer
> > to the message returned by the kernel.
> >
> > Adding a new function allows commands to be moved over to the
> > extended error reporting over time.
> >
> > For feedback, compile tested only.
>
> Just out of curiosity, what is the plan regarding converting iproute2
> over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
> user merged that requires libmnl, the only other user today in the
> tree is devlink, which even seems to define its own libmnl library
> helpers. What is the clear benefit/rationale of outsourcing this to
> libmnl? I always was the impression we should strive for as little
> dependencies as possible?

And I would like to get direction for the RDMA tool [1] which I'm
working on it now.

The overall decision was to use netlink and put it under iproute2
umbrella. Currently, I have working RFC which is based on
legacy sysfs interface to ensure that we are converging on
user-experience even before moving to actual netlink defines.

An I would like to continue to work on netlink interface, but which lib interface
should I need to base rdmatool's netlink code?

[1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html

>
> I don't really like that we make extended ack reporting now dependent
> on libmnl, which further diverts from iproute's native nl library vs
> requiring to install another nl library, making the current status
> quo even worse ... :/
>
> Thanks,
> Daniel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 14:27   ` David Ahern
@ 2017-05-04 14:41     ` David Miller
  2017-05-04 15:50       ` Jamal Hadi Salim
  2017-05-04 16:43       ` Stephen Hemminger
  0 siblings, 2 replies; 27+ messages in thread
From: David Miller @ 2017-05-04 14:41 UTC (permalink / raw)
  To: dsahern; +Cc: daniel, stephen, netdev

From: David Ahern <dsahern@gmail.com>
Date: Thu, 4 May 2017 08:27:35 -0600

> On 5/4/17 3:36 AM, Daniel Borkmann wrote:
>> What is the clear benefit/rationale of outsourcing this to
>> libmnl? I always was the impression we should strive for as little
>> dependencies as possible?
> 
> +1

Agreed, all else being equal iproute2 should be as self contained
as possible since it is such a fundamental tool.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 14:41     ` David Miller
@ 2017-05-04 15:50       ` Jamal Hadi Salim
  2017-05-04 16:43       ` Stephen Hemminger
  1 sibling, 0 replies; 27+ messages in thread
From: Jamal Hadi Salim @ 2017-05-04 15:50 UTC (permalink / raw)
  To: David Miller, dsahern; +Cc: daniel, stephen, netdev

On 17-05-04 10:41 AM, David Miller wrote:
> From: David Ahern <dsahern@gmail.com>
> Date: Thu, 4 May 2017 08:27:35 -0600
>
>> On 5/4/17 3:36 AM, Daniel Borkmann wrote:
>>> What is the clear benefit/rationale of outsourcing this to
>>> libmnl? I always was the impression we should strive for as little
>>> dependencies as possible?
>>
>> +1
>
> Agreed, all else being equal iproute2 should be as self contained
> as possible since it is such a fundamental tool.
>

True, but:->
iproute2 _already_ depends on libmnl;-> (latest user being devlink).

cheers,
jamal

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04  9:36 ` Daniel Borkmann
  2017-05-04 14:27   ` David Ahern
  2017-05-04 14:37   ` Leon Romanovsky
@ 2017-05-04 16:42   ` Stephen Hemminger
  2 siblings, 0 replies; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-04 16:42 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: netdev

On Thu, 04 May 2017 11:36:36 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:

> On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
> > Add support for extended ack error reporting via libmnl. This
> > is a better alternative to use existing library and not copy/paste
> > code from the kernel. Also make arguments const where possible.
> >
> > Add a new function rtnl_talk_extack that takes a callback as an input
> > arg. If a netlink response contains extack attributes, the callback is
> > is invoked with the the err string, offset in the message and a pointer
> > to the message returned by the kernel.
> >
> > Adding a new function allows commands to be moved over to the
> > extended error reporting over time.
> >
> > For feedback, compile tested only.  
> 
> Just out of curiosity, what is the plan regarding converting iproute2
> over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
> user merged that requires libmnl, the only other user today in the
> tree is devlink, which even seems to define its own libmnl library
> helpers. What is the clear benefit/rationale of outsourcing this to
> libmnl? I always was the impression we should strive for as little
> dependencies as possible?
> 
> I don't really like that we make extended ack reporting now dependent
> on libmnl, which further diverts from iproute's native nl library vs
> requiring to install another nl library, making the current status
> quo even worse ... :/
> 
> Thanks,
> Daniel

No rush for migration. just slow migration as time permits.
This would be good kernel janitor type project.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 14:41     ` David Miller
  2017-05-04 15:50       ` Jamal Hadi Salim
@ 2017-05-04 16:43       ` Stephen Hemminger
  2017-05-04 20:43         ` Phil Sutter
  1 sibling, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-04 16:43 UTC (permalink / raw)
  To: David Miller; +Cc: dsahern, daniel, netdev

On Thu, 04 May 2017 10:41:03 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:

> From: David Ahern <dsahern@gmail.com>
> Date: Thu, 4 May 2017 08:27:35 -0600
> 
> > On 5/4/17 3:36 AM, Daniel Borkmann wrote:  
> >> What is the clear benefit/rationale of outsourcing this to
> >> libmnl? I always was the impression we should strive for as little
> >> dependencies as possible?  
> > 
> > +1  
> 
> Agreed, all else being equal iproute2 should be as self contained
> as possible since it is such a fundamental tool.

Sorry, the old netlink code is more difficult to understand than libmnl.
Having dependency on a library is not a problem. There already is
an alternative implementation of ip commands in busybox for those
people trying to work in small environments.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 14:37   ` Leon Romanovsky
@ 2017-05-04 16:45     ` Stephen Hemminger
  2017-05-04 17:55       ` Leon Romanovsky
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-04 16:45 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Daniel Borkmann, netdev

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

On Thu, 4 May 2017 17:37:38 +0300
Leon Romanovsky <leon@kernel.org> wrote:

> On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann wrote:
> > On 05/04/2017 01:56 AM, Stephen Hemminger wrote:  
> > > Add support for extended ack error reporting via libmnl. This
> > > is a better alternative to use existing library and not copy/paste
> > > code from the kernel. Also make arguments const where possible.
> > >
> > > Add a new function rtnl_talk_extack that takes a callback as an input
> > > arg. If a netlink response contains extack attributes, the callback is
> > > is invoked with the the err string, offset in the message and a pointer
> > > to the message returned by the kernel.
> > >
> > > Adding a new function allows commands to be moved over to the
> > > extended error reporting over time.
> > >
> > > For feedback, compile tested only.  
> >
> > Just out of curiosity, what is the plan regarding converting iproute2
> > over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
> > user merged that requires libmnl, the only other user today in the
> > tree is devlink, which even seems to define its own libmnl library
> > helpers. What is the clear benefit/rationale of outsourcing this to
> > libmnl? I always was the impression we should strive for as little
> > dependencies as possible?  
> 
> And I would like to get direction for the RDMA tool [1] which I'm
> working on it now.
> 
> The overall decision was to use netlink and put it under iproute2
> umbrella. Currently, I have working RFC which is based on
> legacy sysfs interface to ensure that we are converging on
> user-experience even before moving to actual netlink defines.
> 
> An I would like to continue to work on netlink interface, but which lib interface
> should I need to base rdmatool's netlink code?
> 
> [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html
> 
> >
> > I don't really like that we make extended ack reporting now dependent
> > on libmnl, which further diverts from iproute's native nl library vs
> > requiring to install another nl library, making the current status
> > quo even worse ... :/
> >
> > Thanks,
> > Daniel  

I would prefer new code use libmnl, but using libnetlink would also be ok.
Any later conversion to libmnl would be mostly automated anyway.

The real objection was copy/pasting in the kernel netlink parser.
That was unnecessary bloat.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 16:45     ` Stephen Hemminger
@ 2017-05-04 17:55       ` Leon Romanovsky
  2017-05-06 10:36         ` Jiri Pirko
  0 siblings, 1 reply; 27+ messages in thread
From: Leon Romanovsky @ 2017-05-04 17:55 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Daniel Borkmann, netdev

[-- Attachment #1: Type: text/plain, Size: 2617 bytes --]

On Thu, May 04, 2017 at 09:45:58AM -0700, Stephen Hemminger wrote:
> On Thu, 4 May 2017 17:37:38 +0300
> Leon Romanovsky <leon@kernel.org> wrote:
>
> > On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann wrote:
> > > On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
> > > > Add support for extended ack error reporting via libmnl. This
> > > > is a better alternative to use existing library and not copy/paste
> > > > code from the kernel. Also make arguments const where possible.
> > > >
> > > > Add a new function rtnl_talk_extack that takes a callback as an input
> > > > arg. If a netlink response contains extack attributes, the callback is
> > > > is invoked with the the err string, offset in the message and a pointer
> > > > to the message returned by the kernel.
> > > >
> > > > Adding a new function allows commands to be moved over to the
> > > > extended error reporting over time.
> > > >
> > > > For feedback, compile tested only.
> > >
> > > Just out of curiosity, what is the plan regarding converting iproute2
> > > over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
> > > user merged that requires libmnl, the only other user today in the
> > > tree is devlink, which even seems to define its own libmnl library
> > > helpers. What is the clear benefit/rationale of outsourcing this to
> > > libmnl? I always was the impression we should strive for as little
> > > dependencies as possible?
> >
> > And I would like to get direction for the RDMA tool [1] which I'm
> > working on it now.
> >
> > The overall decision was to use netlink and put it under iproute2
> > umbrella. Currently, I have working RFC which is based on
> > legacy sysfs interface to ensure that we are converging on
> > user-experience even before moving to actual netlink defines.
> >
> > An I would like to continue to work on netlink interface, but which lib interface
> > should I need to base rdmatool's netlink code?
> >
> > [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html
> >
> > >
> > > I don't really like that we make extended ack reporting now dependent
> > > on libmnl, which further diverts from iproute's native nl library vs
> > > requiring to install another nl library, making the current status
> > > quo even worse ... :/
> > >
> > > Thanks,
> > > Daniel
>
> I would prefer new code use libmnl, but using libnetlink would also be ok.
> Any later conversion to libmnl would be mostly automated anyway.

Thanks, I'm copy/pasting devlink variation of libmnl :)

>
> The real objection was copy/pasting in the kernel netlink parser.
> That was unnecessary bloat.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 16:43       ` Stephen Hemminger
@ 2017-05-04 20:43         ` Phil Sutter
  2017-05-14  1:29           ` David Ahern
  0 siblings, 1 reply; 27+ messages in thread
From: Phil Sutter @ 2017-05-04 20:43 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, dsahern, daniel, netdev

Hi,

On Thu, May 04, 2017 at 09:43:56AM -0700, Stephen Hemminger wrote:
> On Thu, 04 May 2017 10:41:03 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
> 
> > From: David Ahern <dsahern@gmail.com>
> > Date: Thu, 4 May 2017 08:27:35 -0600
> > 
> > > On 5/4/17 3:36 AM, Daniel Borkmann wrote:  
> > >> What is the clear benefit/rationale of outsourcing this to
> > >> libmnl? I always was the impression we should strive for as little
> > >> dependencies as possible?  
> > > 
> > > +1  
> > 
> > Agreed, all else being equal iproute2 should be as self contained
> > as possible since it is such a fundamental tool.
> 
> Sorry, the old netlink code is more difficult to understand than libmnl.
> Having dependency on a library is not a problem. There already is
> an alternative implementation of ip commands in busybox for those
> people trying to work in small environments.

I second that. If you can't afford the extra ~24KB of libmnl on your
system, you much rather can't afford the 20 times bigger ip binary,
either.

Regarding conversion to libmnl, which I investigated and started working
on once: My gut feeling back then was that it's not quite worth the
effor since iproute2 requires an intermediate layer of functions anyway.
Another detail which I didn't like that much was libmnl's idiom of
creating netlink messages on base of just a plain buffer and using
mnl_nlmsg_put_header() et al. to populate it with data. I'm probably a
bit biased since I did the conversion to c99-style initializers for the
various struct req data types, but I didn't like the added run-time
overhead to achieve just the same.

So in summary, given that very little change happens to iproute2's
internal libnetlink, I don't see much urge to make it use libmnl as
backend. In my opinion it just adds another potential source of errors.

Eventually this should be a maintainer level decision, though. :)

Cheers, Phil

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 17:55       ` Leon Romanovsky
@ 2017-05-06 10:36         ` Jiri Pirko
  0 siblings, 0 replies; 27+ messages in thread
From: Jiri Pirko @ 2017-05-06 10:36 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Stephen Hemminger, Daniel Borkmann, netdev

Thu, May 04, 2017 at 07:55:56PM CEST, leon@kernel.org wrote:
>On Thu, May 04, 2017 at 09:45:58AM -0700, Stephen Hemminger wrote:
>> On Thu, 4 May 2017 17:37:38 +0300
>> Leon Romanovsky <leon@kernel.org> wrote:
>>
>> > On Thu, May 04, 2017 at 11:36:36AM +0200, Daniel Borkmann wrote:
>> > > On 05/04/2017 01:56 AM, Stephen Hemminger wrote:
>> > > > Add support for extended ack error reporting via libmnl. This
>> > > > is a better alternative to use existing library and not copy/paste
>> > > > code from the kernel. Also make arguments const where possible.
>> > > >
>> > > > Add a new function rtnl_talk_extack that takes a callback as an input
>> > > > arg. If a netlink response contains extack attributes, the callback is
>> > > > is invoked with the the err string, offset in the message and a pointer
>> > > > to the message returned by the kernel.
>> > > >
>> > > > Adding a new function allows commands to be moved over to the
>> > > > extended error reporting over time.
>> > > >
>> > > > For feedback, compile tested only.
>> > >
>> > > Just out of curiosity, what is the plan regarding converting iproute2
>> > > over to libmnl (ip, tc, ss, ...)? In 2015, tipc tool was the first
>> > > user merged that requires libmnl, the only other user today in the
>> > > tree is devlink, which even seems to define its own libmnl library
>> > > helpers. What is the clear benefit/rationale of outsourcing this to
>> > > libmnl? I always was the impression we should strive for as little
>> > > dependencies as possible?
>> >
>> > And I would like to get direction for the RDMA tool [1] which I'm
>> > working on it now.
>> >
>> > The overall decision was to use netlink and put it under iproute2
>> > umbrella. Currently, I have working RFC which is based on
>> > legacy sysfs interface to ensure that we are converging on
>> > user-experience even before moving to actual netlink defines.
>> >
>> > An I would like to continue to work on netlink interface, but which lib interface
>> > should I need to base rdmatool's netlink code?
>> >
>> > [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg148523.html
>> >
>> > >
>> > > I don't really like that we make extended ack reporting now dependent
>> > > on libmnl, which further diverts from iproute's native nl library vs
>> > > requiring to install another nl library, making the current status
>> > > quo even worse ... :/
>> > >
>> > > Thanks,
>> > > Daniel
>>
>> I would prefer new code use libmnl, but using libnetlink would also be ok.
>> Any later conversion to libmnl would be mostly automated anyway.
>
>Thanks, I'm copy/pasting devlink variation of libmnl :)

I needed couple of small helpers for generic netlink support. I believe
they could be pushed to upstream libmnl so we can avoid having them in
iproute2


>
>>
>> The real objection was copy/pasting in the kernel netlink parser.
>> That was unnecessary bloat.
>
>

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-04 20:43         ` Phil Sutter
@ 2017-05-14  1:29           ` David Ahern
  2017-05-16 16:36             ` Stephen Hemminger
  0 siblings, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-05-14  1:29 UTC (permalink / raw)
  To: Phil Sutter, Stephen Hemminger, David Miller, daniel, netdev

On 5/4/17 2:43 PM, Phil Sutter wrote:
> So in summary, given that very little change happens to iproute2's
> internal libnetlink, I don't see much urge to make it use libmnl as
> backend. In my opinion it just adds another potential source of errors.
> 
> Eventually this should be a maintainer level decision, though. :)

What is the decision on this?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-14  1:29           ` David Ahern
@ 2017-05-16 16:36             ` Stephen Hemminger
  2017-05-18 10:02               ` Daniel Borkmann
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-16 16:36 UTC (permalink / raw)
  To: David Ahern; +Cc: Phil Sutter, David Miller, daniel, netdev

On Sat, 13 May 2017 19:29:57 -0600
David Ahern <dsahern@gmail.com> wrote:

> On 5/4/17 2:43 PM, Phil Sutter wrote:
> > So in summary, given that very little change happens to iproute2's
> > internal libnetlink, I don't see much urge to make it use libmnl as
> > backend. In my opinion it just adds another potential source of errors.
> > 
> > Eventually this should be a maintainer level decision, though. :)  
> 
> What is the decision on this?

I am waiting for a longer before committing anything. This was to allow
for a wider range of distribution maintainer feedback.

The most likely outcome is that for 4.12 is to use libmnl for extended ack.
And continue to support building without mnl with loss of functionality.

As far as conversion of all of iproute2 to libmnl. I have better things
to do... But for new functionality like extended ack, devlink, tipc, using
libmnl is easy, safe and it works well. I will continue to not accept
new  code that depends on the other library (libnl). That has come up
a couple of times.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-16 16:36             ` Stephen Hemminger
@ 2017-05-18 10:02               ` Daniel Borkmann
  2017-05-18 14:55                 ` Stephen Hemminger
  2017-05-19  4:24                 ` David Ahern
  0 siblings, 2 replies; 27+ messages in thread
From: Daniel Borkmann @ 2017-05-18 10:02 UTC (permalink / raw)
  To: Stephen Hemminger, David Ahern; +Cc: Phil Sutter, David Miller, netdev

On 05/16/2017 06:36 PM, Stephen Hemminger wrote:
> On Sat, 13 May 2017 19:29:57 -0600
> David Ahern <dsahern@gmail.com> wrote:
>
>> On 5/4/17 2:43 PM, Phil Sutter wrote:
>>> So in summary, given that very little change happens to iproute2's
>>> internal libnetlink, I don't see much urge to make it use libmnl as
>>> backend. In my opinion it just adds another potential source of errors.
>>>
>>> Eventually this should be a maintainer level decision, though. :)
>>
>> What is the decision on this?
>
> I am waiting for a longer before committing anything. This was to allow
> for a wider range of distribution maintainer feedback.
>
> The most likely outcome is that for 4.12 is to use libmnl for extended ack.
> And continue to support building without mnl with loss of functionality.
>
> As far as conversion of all of iproute2 to libmnl. I have better things
> to do... But for new functionality like extended ack, devlink, tipc, using
> libmnl is easy, safe and it works well. I will continue to not accept
> new  code that depends on the other library (libnl). That has come up
> a couple of times.

So effectively this means libmnl has to be used for new stuff, noone
has time to do the work to convert the existing tooling over (which
by itself might be a challenge in testing everything to make sure
there are no regressions) given there's not much activity around
lib/libnetlink.c anyway, and existing users not using libmnl today
won't see/notice new improvements on netlink side when they do an
upgrade. So we'll be stuck with that dual library mess pretty much
for a very long time. :(

If there's such high desire to use libmnl (?), can't there be a
one time effort wrapping the core netlink code over, making a hard
cut for everyone where from one release to another the dependency
becomes really mandatory rather than optional? That's more work
initially, but still seems a lot better than growing a wild mix
of both over time where users see different behavior of the tools
depending on their setup. (This could perhaps also make actual
conversion much harder later on.)

Can't you add that lib conversion as a Google summer of code project,
so that someone is actively taking care of that initial work?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-18 10:02               ` Daniel Borkmann
@ 2017-05-18 14:55                 ` Stephen Hemminger
  2017-05-19  4:24                 ` David Ahern
  1 sibling, 0 replies; 27+ messages in thread
From: Stephen Hemminger @ 2017-05-18 14:55 UTC (permalink / raw)
  To: Daniel Borkmann; +Cc: David Ahern, Phil Sutter, David Miller, netdev

On Thu, 18 May 2017 12:02:07 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:

> On 05/16/2017 06:36 PM, Stephen Hemminger wrote:
> > On Sat, 13 May 2017 19:29:57 -0600
> > David Ahern <dsahern@gmail.com> wrote:
> >  
> >> On 5/4/17 2:43 PM, Phil Sutter wrote:  
> >>> So in summary, given that very little change happens to iproute2's
> >>> internal libnetlink, I don't see much urge to make it use libmnl as
> >>> backend. In my opinion it just adds another potential source of errors.
> >>>
> >>> Eventually this should be a maintainer level decision, though. :)  
> >>
> >> What is the decision on this?  
> >
> > I am waiting for a longer before committing anything. This was to allow
> > for a wider range of distribution maintainer feedback.
> >
> > The most likely outcome is that for 4.12 is to use libmnl for extended ack.
> > And continue to support building without mnl with loss of functionality.
> >
> > As far as conversion of all of iproute2 to libmnl. I have better things
> > to do... But for new functionality like extended ack, devlink, tipc, using
> > libmnl is easy, safe and it works well. I will continue to not accept
> > new  code that depends on the other library (libnl). That has come up
> > a couple of times.  
> 
> So effectively this means libmnl has to be used for new stuff, noone
> has time to do the work to convert the existing tooling over (which
> by itself might be a challenge in testing everything to make sure
> there are no regressions) given there's not much activity around
> lib/libnetlink.c anyway, and existing users not using libmnl today
> won't see/notice new improvements on netlink side when they do an
> upgrade. So we'll be stuck with that dual library mess pretty much
> for a very long time. :(
> 
> If there's such high desire to use libmnl (?), can't there be a
> one time effort wrapping the core netlink code over, making a hard
> cut for everyone where from one release to another the dependency
> becomes really mandatory rather than optional? That's more work
> initially, but still seems a lot better than growing a wild mix
> of both over time where users see different behavior of the tools
> depending on their setup. (This could perhaps also make actual
> conversion much harder later on.)

If nothing else it would be simple experiment to do libnetlink
to libmnl wrappers in libnetlink.h

> Can't you add that lib conversion as a Google summer of code project,
> so that someone is actively taking care of that initial work?

Agreed

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-18 10:02               ` Daniel Borkmann
  2017-05-18 14:55                 ` Stephen Hemminger
@ 2017-05-19  4:24                 ` David Ahern
  2017-08-03 20:26                   ` David Ahern
  1 sibling, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-05-19  4:24 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Hemminger; +Cc: Phil Sutter, David Miller, netdev

On 5/18/17 3:02 AM, Daniel Borkmann wrote:
> So effectively this means libmnl has to be used for new stuff, noone
> has time to do the work to convert the existing tooling over (which
> by itself might be a challenge in testing everything to make sure
> there are no regressions) given there's not much activity around
> lib/libnetlink.c anyway, and existing users not using libmnl today
> won't see/notice new improvements on netlink side when they do an
> upgrade. So we'll be stuck with that dual library mess pretty much
> for a very long time. :(

lib/libnetlink.c with all of its duplicate functions weighs in at just
947 LOC -- a mere 12% of the code in lib/. From a total SLOC of iproute2
it is a negligible part of the code base.

Given that, there is very little gain -- but a lot of risk in
regressions -- in converting such a small, low level code base to libmnl
just for the sake of using a library - something Phil noted in his
cursory attempt at converting ip to libmnl. ie., The level effort
required vs the benefit is just not worth it.

There are so many other parts of the ip code base that need work with a
much higher return on the time investment.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-05-19  4:24                 ` David Ahern
@ 2017-08-03 20:26                   ` David Ahern
  2017-08-04 11:31                     ` Simon Horman
  0 siblings, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-08-03 20:26 UTC (permalink / raw)
  To: Daniel Borkmann, Stephen Hemminger; +Cc: Phil Sutter, David Miller, netdev

On 5/18/17 10:24 PM, David Ahern wrote:
> On 5/18/17 3:02 AM, Daniel Borkmann wrote:
>> So effectively this means libmnl has to be used for new stuff, noone
>> has time to do the work to convert the existing tooling over (which
>> by itself might be a challenge in testing everything to make sure
>> there are no regressions) given there's not much activity around
>> lib/libnetlink.c anyway, and existing users not using libmnl today
>> won't see/notice new improvements on netlink side when they do an
>> upgrade. So we'll be stuck with that dual library mess pretty much
>> for a very long time. :(
> 
> lib/libnetlink.c with all of its duplicate functions weighs in at just
> 947 LOC -- a mere 12% of the code in lib/. From a total SLOC of iproute2
> it is a negligible part of the code base.
> 
> Given that, there is very little gain -- but a lot of risk in
> regressions -- in converting such a small, low level code base to libmnl
> just for the sake of using a library - something Phil noted in his
> cursory attempt at converting ip to libmnl. ie., The level effort
> required vs the benefit is just not worth it.
> 
> There are so many other parts of the ip code base that need work with a
> much higher return on the time investment.
> 

Stephen: It has been 3 months since the first extack patches were posted
and still nothing in iproute2, all of it hung up on your decision to
require libmnl. Do you plan to finish the libmnl support any time soon
and send out patches?

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-03 20:26                   ` David Ahern
@ 2017-08-04 11:31                     ` Simon Horman
  2017-08-04 16:47                       ` Stephen Hemminger
  0 siblings, 1 reply; 27+ messages in thread
From: Simon Horman @ 2017-08-04 11:31 UTC (permalink / raw)
  To: David Ahern
  Cc: Daniel Borkmann, Stephen Hemminger, Phil Sutter, David Miller, netdev

On Thu, Aug 03, 2017 at 02:26:58PM -0600, David Ahern wrote:
> On 5/18/17 10:24 PM, David Ahern wrote:
> > On 5/18/17 3:02 AM, Daniel Borkmann wrote:
> >> So effectively this means libmnl has to be used for new stuff, noone
> >> has time to do the work to convert the existing tooling over (which
> >> by itself might be a challenge in testing everything to make sure
> >> there are no regressions) given there's not much activity around
> >> lib/libnetlink.c anyway, and existing users not using libmnl today
> >> won't see/notice new improvements on netlink side when they do an
> >> upgrade. So we'll be stuck with that dual library mess pretty much
> >> for a very long time. :(
> > 
> > lib/libnetlink.c with all of its duplicate functions weighs in at just
> > 947 LOC -- a mere 12% of the code in lib/. From a total SLOC of iproute2
> > it is a negligible part of the code base.
> > 
> > Given that, there is very little gain -- but a lot of risk in
> > regressions -- in converting such a small, low level code base to libmnl
> > just for the sake of using a library - something Phil noted in his
> > cursory attempt at converting ip to libmnl. ie., The level effort
> > required vs the benefit is just not worth it.
> > 
> > There are so many other parts of the ip code base that need work with a
> > much higher return on the time investment.
> > 
> 
> Stephen: It has been 3 months since the first extack patches were posted
> and still nothing in iproute2, all of it hung up on your decision to
> require libmnl. Do you plan to finish the libmnl support any time soon
> and send out patches?

FWIIW I would also like to see some way to get this enhancement accepted.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-04 11:31                     ` Simon Horman
@ 2017-08-04 16:47                       ` Stephen Hemminger
  2017-08-07 16:48                         ` David Ahern
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-08-04 16:47 UTC (permalink / raw)
  To: Simon Horman
  Cc: David Ahern, Daniel Borkmann, Phil Sutter, David Miller, netdev

On Fri, 4 Aug 2017 13:31:48 +0200
Simon Horman <simon.horman@netronome.com> wrote:

> On Thu, Aug 03, 2017 at 02:26:58PM -0600, David Ahern wrote:
> > On 5/18/17 10:24 PM, David Ahern wrote:  
> > > On 5/18/17 3:02 AM, Daniel Borkmann wrote:  
> > >> So effectively this means libmnl has to be used for new stuff, noone
> > >> has time to do the work to convert the existing tooling over (which
> > >> by itself might be a challenge in testing everything to make sure
> > >> there are no regressions) given there's not much activity around
> > >> lib/libnetlink.c anyway, and existing users not using libmnl today
> > >> won't see/notice new improvements on netlink side when they do an
> > >> upgrade. So we'll be stuck with that dual library mess pretty much
> > >> for a very long time. :(  
> > > 
> > > lib/libnetlink.c with all of its duplicate functions weighs in at just
> > > 947 LOC -- a mere 12% of the code in lib/. From a total SLOC of iproute2
> > > it is a negligible part of the code base.
> > > 
> > > Given that, there is very little gain -- but a lot of risk in
> > > regressions -- in converting such a small, low level code base to libmnl
> > > just for the sake of using a library - something Phil noted in his
> > > cursory attempt at converting ip to libmnl. ie., The level effort
> > > required vs the benefit is just not worth it.
> > > 
> > > There are so many other parts of the ip code base that need work with a
> > > much higher return on the time investment.
> > >   
> > 
> > Stephen: It has been 3 months since the first extack patches were posted
> > and still nothing in iproute2, all of it hung up on your decision to
> > require libmnl. Do you plan to finish the libmnl support any time soon
> > and send out patches?  
> 
> FWIIW I would also like to see some way to get this enhancement accepted.

I will put in the libmnl version. If it doesn't work because no one sent
me test cases, then fine. send a patch for that.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-04 16:47                       ` Stephen Hemminger
@ 2017-08-07 16:48                         ` David Ahern
  2017-08-07 18:06                           ` Stephen Hemminger
  0 siblings, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-08-07 16:48 UTC (permalink / raw)
  To: Stephen Hemminger, Simon Horman
  Cc: Daniel Borkmann, Phil Sutter, David Miller, netdev

On 8/4/17 10:47 AM, Stephen Hemminger wrote:
> I will put in the libmnl version. If it doesn't work because no one sent
> me test cases, then fine. send a patch for that.

This commit:

commit b6432e68ac2f1f6b4ea50aa0d6d47e72c445c71c
Author: Stephen Hemminger <stephen@networkplumber.org>
Date:   Fri Aug 4 09:52:15 2017 -0700

    iproute: Add support for extended ack to rtnl_talk


Does not work. Seems like you pushed the RFC commit which was known to
be incomplete.


First, the Config is HAVE_MNL not HAVE_LIBMNL which is in lib/libnetlink.c.

Second, changing that to HAVE_MNL does not work -- something is not
getting passed in correctly. Just remove the semicolon on the else path:

+#else
+/* No extended error ack without libmnl */
+static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t
errfn)
+{
+       return 0;
+}
+#endif

and you will see that HAVE_MNL is never defined.

Third, force that path to build and you get:

ip
    LINK     ip
../lib/libnetlink.a(libnetlink.o): In function `err_attr_cb':
libnetlink.c:(.text+0x10): undefined reference to `mnl_attr_type_valid'
libnetlink.c:(.text+0x1c): undefined reference to `mnl_attr_get_type'
libnetlink.c:(.text+0x34): undefined reference to `mnl_attr_validate'
../lib/libnetlink.a(libnetlink.o): In function `__rtnl_talk':
libnetlink.c:(.text+0x408): undefined reference to `mnl_nlmsg_get_payload'
libnetlink.c:(.text+0x42c): undefined reference to
`mnl_nlmsg_get_payload_len'
libnetlink.c:(.text+0x445): undefined reference to `mnl_attr_parse'
libnetlink.c:(.text+0x454): undefined reference to `mnl_attr_get_str'
libnetlink.c:(.text+0x46a): undefined reference to `mnl_attr_get_u32'
collect2: error: ld returned 1 exit status
Makefile:29: recipe for target 'ip' failed
make[1]: *** [ip] Error 1
Makefile:66: recipe for target 'all' failed
make: *** [all] Error 2


as I mentioned in a past response the libmnl dependency can not be
placed on libutil.a -- because it is an archive. That means each and
every command that uses libutil.a needs to inherit the libmnl dependency.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 16:48                         ` David Ahern
@ 2017-08-07 18:06                           ` Stephen Hemminger
  2017-08-07 18:09                             ` David Ahern
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-08-07 18:06 UTC (permalink / raw)
  To: David Ahern
  Cc: Simon Horman, Daniel Borkmann, Phil Sutter, David Miller, netdev

On Mon, 7 Aug 2017 10:48:23 -0600
David Ahern <dsahern@gmail.com> wrote:

> On 8/4/17 10:47 AM, Stephen Hemminger wrote:
> > I will put in the libmnl version. If it doesn't work because no one sent
> > me test cases, then fine. send a patch for that.  
> 
> This commit:
> 
> commit b6432e68ac2f1f6b4ea50aa0d6d47e72c445c71c
> Author: Stephen Hemminger <stephen@networkplumber.org>
> Date:   Fri Aug 4 09:52:15 2017 -0700
> 
>     iproute: Add support for extended ack to rtnl_talk
> 
> 
> Does not work. Seems like you pushed the RFC commit which was known to
> be incomplete.

Patches welcome.

> First, the Config is HAVE_MNL not HAVE_LIBMNL which is in lib/libnetlink.c.
> 
> Second, changing that to HAVE_MNL does not work -- something is not
> getting passed in correctly. Just remove the semicolon on the else path:
> 
> +#else
> +/* No extended error ack without libmnl */
> +static int nl_dump_ext_err(const struct nlmsghdr *nlh, nl_ext_ack_fn_t
> errfn)
> +{
> +       return 0;
> +}
> +#endif
> 
> and you will see that HAVE_MNL is never defined.

Ok, that I will fix.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 18:06                           ` Stephen Hemminger
@ 2017-08-07 18:09                             ` David Ahern
  2017-08-07 18:45                               ` David Miller
  0 siblings, 1 reply; 27+ messages in thread
From: David Ahern @ 2017-08-07 18:09 UTC (permalink / raw)
  To: Stephen Hemminger
  Cc: Simon Horman, Daniel Borkmann, Phil Sutter, David Miller, netdev

On 8/7/17 12:06 PM, Stephen Hemminger wrote:
>> Does not work. Seems like you pushed the RFC commit which was known to
>> be incomplete.
> 
> Patches welcome.

What exists does not even compile. Patches will be sent once you fix that.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 18:09                             ` David Ahern
@ 2017-08-07 18:45                               ` David Miller
  2017-08-07 19:12                                 ` Stephen Hemminger
  0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2017-08-07 18:45 UTC (permalink / raw)
  To: dsahern; +Cc: stephen, simon.horman, daniel, phil, netdev

From: David Ahern <dsahern@gmail.com>
Date: Mon, 7 Aug 2017 12:09:31 -0600

> On 8/7/17 12:06 PM, Stephen Hemminger wrote:
>>> Does not work. Seems like you pushed the RFC commit which was known to
>>> be incomplete.
>> 
>> Patches welcome.
> 
> What exists does not even compile. Patches will be sent once you fix that.

Yeah seriously Stephen, you created this huge mess so the onus is really
on you to fix it up.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 18:45                               ` David Miller
@ 2017-08-07 19:12                                 ` Stephen Hemminger
  2017-08-07 20:26                                   ` David Miller
  0 siblings, 1 reply; 27+ messages in thread
From: Stephen Hemminger @ 2017-08-07 19:12 UTC (permalink / raw)
  To: David Miller; +Cc: dsahern, simon.horman, daniel, phil, netdev

On Mon, 07 Aug 2017 11:45:17 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: David Ahern <dsahern@gmail.com>
> Date: Mon, 7 Aug 2017 12:09:31 -0600
> 
> > On 8/7/17 12:06 PM, Stephen Hemminger wrote:  
> >>> Does not work. Seems like you pushed the RFC commit which was known to
> >>> be incomplete.  
> >> 
> >> Patches welcome.  
> > 
> > What exists does not even compile. Patches will be sent once you fix that.  
> 
> Yeah seriously Stephen, you created this huge mess so the onus is really
> on you to fix it up.

It is fixed now.
Dave, I asked for test cases, and received none.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 19:12                                 ` Stephen Hemminger
@ 2017-08-07 20:26                                   ` David Miller
  2017-08-07 21:21                                     ` Stephen Hemminger
  0 siblings, 1 reply; 27+ messages in thread
From: David Miller @ 2017-08-07 20:26 UTC (permalink / raw)
  To: stephen; +Cc: dsahern, simon.horman, daniel, phil, netdev

From: Stephen Hemminger <stephen@networkplumber.org>
Date: Mon, 7 Aug 2017 12:12:35 -0700

> Dave, I asked for test cases, and received none.

You don't need a test case to type make and make sure the build succeeds.

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC] iproute: Add support for extended ack to rtnl_talk
  2017-08-07 20:26                                   ` David Miller
@ 2017-08-07 21:21                                     ` Stephen Hemminger
  0 siblings, 0 replies; 27+ messages in thread
From: Stephen Hemminger @ 2017-08-07 21:21 UTC (permalink / raw)
  To: David Miller; +Cc: dsahern, simon.horman, daniel, phil, netdev

On Mon, 07 Aug 2017 13:26:03 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> From: Stephen Hemminger <stephen@networkplumber.org>
> Date: Mon, 7 Aug 2017 12:12:35 -0700
> 
> > Dave, I asked for test cases, and received none.  
> 
> You don't need a test case to type make and make sure the build succeeds.

It did succeed for libmnl but was not doing anything.

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2017-08-07 21:21 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-03 23:56 [RFC] iproute: Add support for extended ack to rtnl_talk Stephen Hemminger
2017-05-04  9:36 ` Daniel Borkmann
2017-05-04 14:27   ` David Ahern
2017-05-04 14:41     ` David Miller
2017-05-04 15:50       ` Jamal Hadi Salim
2017-05-04 16:43       ` Stephen Hemminger
2017-05-04 20:43         ` Phil Sutter
2017-05-14  1:29           ` David Ahern
2017-05-16 16:36             ` Stephen Hemminger
2017-05-18 10:02               ` Daniel Borkmann
2017-05-18 14:55                 ` Stephen Hemminger
2017-05-19  4:24                 ` David Ahern
2017-08-03 20:26                   ` David Ahern
2017-08-04 11:31                     ` Simon Horman
2017-08-04 16:47                       ` Stephen Hemminger
2017-08-07 16:48                         ` David Ahern
2017-08-07 18:06                           ` Stephen Hemminger
2017-08-07 18:09                             ` David Ahern
2017-08-07 18:45                               ` David Miller
2017-08-07 19:12                                 ` Stephen Hemminger
2017-08-07 20:26                                   ` David Miller
2017-08-07 21:21                                     ` Stephen Hemminger
2017-05-04 14:37   ` Leon Romanovsky
2017-05-04 16:45     ` Stephen Hemminger
2017-05-04 17:55       ` Leon Romanovsky
2017-05-06 10:36         ` Jiri Pirko
2017-05-04 16:42   ` Stephen Hemminger

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.