On 6/12/19 3:21 AM, Hangbin Liu wrote:
> Add a new parameter '-Numeric' to show the number of protocol, scope,
> dsfield, etc directly instead of converting it to human readable name.
> Do the same on tc and ss.
>
> This patch is based on David Ahern's previous patch.
>
> Suggested-by: Phil Sutte
On 6/14/19 1:00 PM, Roman Mashak wrote:
> On the 2nd thought: there already exists argument "-raw" for tc which
> currently instructs printing handles in hex representation. Why not to
> adopt this for ip and ss as well rather then adding new key?
show_raw seems to mean dump extra data as opposed
David Ahern writes:
> On 6/12/19 10:01 AM, Roman Mashak wrote:
>> Hangbin Liu writes:
>>
>>> Add a new parameter '-Numeric' to show the number of protocol, scope,
>>> dsfield, etc directly instead of converting it to human readable name.
>>> Do the same on tc and ss.
>>>
>>> This patch is based
On 6/12/19 10:01 AM, Roman Mashak wrote:
> Hangbin Liu writes:
>
>> Add a new parameter '-Numeric' to show the number of protocol, scope,
>> dsfield, etc directly instead of converting it to human readable name.
>> Do the same on tc and ss.
>>
>> This patch is based on David Ahern's previous patc
Hi Roman,
On Wed, Jun 12, 2019 at 12:01:20PM -0400, Roman Mashak wrote:
> Hangbin Liu writes:
>
> > Add a new parameter '-Numeric' to show the number of protocol, scope,
> > dsfield, etc directly instead of converting it to human readable name.
> > Do the same on tc and ss.
> >
> > This patch is
Hangbin Liu writes:
> Add a new parameter '-Numeric' to show the number of protocol, scope,
> dsfield, etc directly instead of converting it to human readable name.
> Do the same on tc and ss.
>
> This patch is based on David Ahern's previous patch.
>
[...]
It would be good idea to specify the
On Wed, 12 Jun 2019 at 17:21, Hangbin Liu wrote:
>
> Add a new parameter '-Numeric' to show the number of protocol, scope,
> dsfield, etc directly instead of converting it to human readable name.
> Do the same on tc and ss.
>
> This patch is based on David Ahern's previous patch.
>
> Suggested-by:
On 1/15/18 8:29 PM, Jakub Kicinski wrote:
> About the branches - what should we base our patches on for net-next?
> Most -next repos just use the master, but it seems that in case of
> iproute2-next.git the net-next branch is still active, and there is
> an inactive net-next branch in iproute2.git.
On 1/15/18 7:29 PM, Jakub Kicinski wrote:
>> Done a few days ago. The new canonical URLs for those repos are:
>> pub/scm/network/iproute2/iproute2
>> pub/scm/network/iproute2/iproute2-next
>>
>> So clone URLs
>> git://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git
>> http
On Mon, 15 Jan 2018 19:59:05 -0700, David Ahern wrote:
> On 1/15/18 6:56 PM, Marcelo Ricardo Leitner wrote:
> > On Fri, Dec 29, 2017 at 08:00:28PM -0800, Stephen Hemminger wrote:
> >> On Fri, 29 Dec 2017 09:58:23 +0100
> >> Jiri Pirko wrote:
> >>
> >>> Fri, Dec 29, 2017 at 12:46:31AM CET, dan.
On 1/15/18 6:56 PM, Marcelo Ricardo Leitner wrote:
> On Fri, Dec 29, 2017 at 08:00:28PM -0800, Stephen Hemminger wrote:
>> On Fri, 29 Dec 2017 09:58:23 +0100
>> Jiri Pirko wrote:
>>
>>> Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote:
On 12/26/2017 10:35 AM, Leon Romanovsky wr
On Fri, Dec 29, 2017 at 08:00:28PM -0800, Stephen Hemminger wrote:
> On Fri, 29 Dec 2017 09:58:23 +0100
> Jiri Pirko wrote:
>
> > Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote:
> > >On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
> > >> On Mon, Dec 25, 2017 at 10:14:26PM -0800,
On 12/30/2017 05:00 AM, Stephen Hemminger wrote:
> On Fri, 29 Dec 2017 09:58:23 +0100
> Jiri Pirko wrote:
>> Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote:
>>> On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
On Fri, 29 Dec 2017 09:58:23 +0100
Jiri Pirko wrote:
> Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote:
> >On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
> >> On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
> >>> On Tue, 26 Dec 2017 06:47:43 +0200
> >>> Leon
Fri, Dec 29, 2017 at 12:46:31AM CET, dan...@iogearbox.net wrote:
>On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
>> On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
>>> On Tue, 26 Dec 2017 06:47:43 +0200
>>> Leon Romanovsky wrote:
>>>
On Mon, Dec 25, 2017 at 10:49:19AM -0800
On 12/26/2017 10:35 AM, Leon Romanovsky wrote:
> On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
>> On Tue, 26 Dec 2017 06:47:43 +0200
>> Leon Romanovsky wrote:
>>
>>> On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote:
David Ahern has agreed to take over man
On Mon, Dec 25, 2017 at 10:14:26PM -0800, Stephen Hemminger wrote:
> On Tue, 26 Dec 2017 06:47:43 +0200
> Leon Romanovsky wrote:
>
> > On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote:
> > > David Ahern has agreed to take over managing the net-next branch of
> > > iproute2.
> > >
On Tue, 26 Dec 2017 06:47:43 +0200
Leon Romanovsky wrote:
> On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote:
> > David Ahern has agreed to take over managing the net-next branch of
> > iproute2.
> > The new location is:
> > https://git.kernel.org/pub/scm/linux/kernel/git/dsahe
On Mon, Dec 25, 2017 at 10:49:19AM -0800, Stephen Hemminger wrote:
> David Ahern has agreed to take over managing the net-next branch of iproute2.
> The new location is:
> https://git.kernel.org/pub/scm/linux/kernel/git/dsahern/iproute2-next.git/
>
> In the past, I have accepted new features into
On 11/29/2017 03:17 AM, Stephen Hemminger wrote:
[...]
> Sorry, net-next branch had out of date headers. Now fixed.
Yeah, master worked fine. Thanks for the fix!
On Wed, 29 Nov 2017 02:05:09 +0100
Daniel Borkmann wrote:
> Hi Stephen,
>
> after merge of master into net-next branch the build is now broken
> for BPF loader as follows:
>
> # make
>
> lib
> make[1]: Entering directory '/home/darkstar/iproute2/lib'
> CC libgenl.o
> CC ll_
On Wed, 29 Nov 2017 02:05:09 +0100
Daniel Borkmann wrote:
> Hi Stephen,
>
> after merge of master into net-next branch the build is now broken
> for BPF loader as follows:
>
> # make
>
> lib
> make[1]: Entering directory '/home/darkstar/iproute2/lib'
> CC libgenl.o
> CC ll_
On Tue, 26 Sep 2017 16:39:56 -0700
Vinicius Costa Gomes wrote:
> Signed-off-by: Vinicius Costa Gomes
I won't apply this patch directly, instead will pick up pkt_sched.h on
next update of net-next headers.
On Thu, 23 Mar 2017 19:51:19 -0700
David Ahern wrote:
> Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
> and just ipv4 for device requests. Improve the user experience by
> using the new kernel patch to dump all address families that have
> registered. For example, if mpls_rout
On 4/4/17 5:39 PM, Stephen Hemminger wrote:
> On Tue, 4 Apr 2017 17:07:31 -0400
> David Ahern wrote:
>
>> On 3/23/17 10:51 PM, David Ahern wrote:
>>> Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
>>> and just ipv4 for device requests. Improve the user experience by
>>> using t
On Tue, 4 Apr 2017 17:07:31 -0400
David Ahern wrote:
> On 3/23/17 10:51 PM, David Ahern wrote:
> > Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
> > and just ipv4 for device requests. Improve the user experience by
> > using the new kernel patch to dump all address families th
On 3/23/17 10:51 PM, David Ahern wrote:
> Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
> and just ipv4 for device requests. Improve the user experience by
> using the new kernel patch to dump all address families that have
> registered. For example, if mpls_router module is loa
Le 24/03/2017 à 03:51, David Ahern a écrit :
> Currently, ip netconf only shows data for ipv4 and ipv6 for dumps
> and just ipv4 for device requests. Improve the user experience by
> using the new kernel patch to dump all address families that have
> registered. For example, if mpls_router module i
Le 22/03/2017 à 22:59, David Ahern a écrit :
> Currently specifying a device to ip netconf and it dumps only values
> for IPv4. Change this to dump data for all families unless a specific
> family is given.
>
> Signed-off-by: David Ahern
> ---
> ip/ipnetconf.c | 23 +--
> 1 f
On 12/12/2016 12:28 PM, Hannes Frederic Sowa wrote:
On 12.12.2016 01:53, David Ahern wrote:
Based on version in kernel repo, samples/bpf/libbpf.h
Signed-off-by: David Ahern
---
include/bpf_util.h | 179 +
1 file changed, 179 insertions(+)
On 12.12.2016 01:53, David Ahern wrote:
> Based on version in kernel repo, samples/bpf/libbpf.h
>
> Signed-off-by: David Ahern
> ---
> include/bpf_util.h | 179
> +
> 1 file changed, 179 insertions(+)
>
> diff --git a/include/bpf_util.h b/inc
On 12/12/2016 01:53 AM, David Ahern wrote:
Based on version in kernel repo, samples/bpf/libbpf.h
Signed-off-by: David Ahern
Acked-by: Daniel Borkmann
On 12/12/2016 01:53 AM, David Ahern wrote:
Code move only; no functional change intended.
Signed-off-by: David Ahern
Acked-by: Daniel Borkmann
On 12/12/2016 01:53 AM, David Ahern wrote:
Signed-off-by: David Ahern
Acked-by: Daniel Borkmann
On 12/10/2016 11:15 PM, David Ahern wrote:
On 12/10/16 2:21 PM, Daniel Borkmann wrote:
Please name it bpf_prog_create() then, it would be consistent to
bpf_map_create() and shorter as well.
Sorry, lack of coffee, scratch that.
Can't the current bpf_prog_attach() stay as is, and you name the
On 12/10/16 2:21 PM, Daniel Borkmann wrote:
>>
>> Please name it bpf_prog_create() then, it would be consistent to
>> bpf_map_create() and shorter as well.
>
> Sorry, lack of coffee, scratch that.
>
> Can't the current bpf_prog_attach() stay as is, and you name the above new
> functions bpf_prog_
On 12/10/2016 09:32 PM, David Ahern wrote:
Based on version in kernel repo, samples/bpf/libbpf.h
Signed-off-by: David Ahern
---
include/libbpf.h | 184 +++
1 file changed, 184 insertions(+)
create mode 100644 include/libbpf.h
diff --git
On 12/10/2016 09:32 PM, David Ahern wrote:
Code move only; no functional change intended.
Signed-off-by: David Ahern
---
include/bpf_util.h | 3 +++
lib/bpf.c | 40
2 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/include/bp
On 12/10/2016 10:16 PM, Daniel Borkmann wrote:
On 12/10/2016 09:32 PM, David Ahern wrote:
For consistency with other bpf commands, the functions are named
bpf_prog_attach and bpf_prog_detach. The existing bpf_prog_attach is
renamed to bpf_prog_load_and_report since it calls bpf_prog_load and
bpf
On 12/10/2016 09:32 PM, David Ahern wrote:
For consistency with other bpf commands, the functions are named
bpf_prog_attach and bpf_prog_detach. The existing bpf_prog_attach is
renamed to bpf_prog_load_and_report since it calls bpf_prog_load and
bpf_prog_report.
Signed-off-by: David Ahern
---
On Sat, 14 May 2016 15:21:01 +0200
Jiri Pirko wrote:
> From: Jiri Pirko
>
> Implement kernel devlink shared buffer interface. Introduce new object
> "sb" and allow to browse the shared buffer parameters and also change
> configuration.
>
> Signed-off-by: Jiri Pirko
> ---
> devlink/devlink.c
On Tue, 2 Feb 2016 07:43:46 -0800
David Ahern wrote:
> Print VRF slave_info attributes if present.
>
> Signed-off-by: David Ahern
Applied to net-next
On Mon, 21 Sep 2015 11:19:48 -0700
David Ahern wrote:
> Currently 'ip route get' does not show the table the lookup result comes
> from and prior to kernel commit c36ba6603a11 the response from the kernel
> was hardcoded to the main table. From the discussion this appears to be
> a leftover from
From: David Ahern
Date: Mon, 21 Sep 2015 16:23:13 -0600
> With the new flag a AND kernel that supports it ip will only show the
> table id IF it is not main:
>
> root@vm-wheezy2:~# ./ip route get 10.0.0.20
> 10.0.0.20 dev eth0 src 10.0.0.2
> cache
>
> root@vm-wheezy2:~# ./ip route get 10.2
On 9/21/15 4:03 PM, David Miller wrote:
From: David Ahern
Date: Mon, 21 Sep 2015 16:03:00 -0600
On 9/21/15 3:58 PM, David Miller wrote:
I think if it always gave MAIN in older kernels, iproute should
continue
to do so.
You can't just remove the table ID output just because you disagree
with
From: David Ahern
Date: Mon, 21 Sep 2015 16:03:00 -0600
> On 9/21/15 3:58 PM, David Miller wrote:
>> I think if it always gave MAIN in older kernels, iproute should
>> continue
>> to do so.
>>
>> You can't just remove the table ID output just because you disagree
>> with
>> the semantics given by
On 9/21/15 3:58 PM, David Miller wrote:
I think if it always gave MAIN in older kernels, iproute should continue
to do so.
You can't just remove the table ID output just because you disagree with
the semantics given by old kernels.
Current semantics are maintained. Kernel was hardcoded to ret
From: David Ahern
Date: Mon, 21 Sep 2015 15:28:53 -0600
> On 9/21/15 3:19 PM, Stephen Hemminger wrote:
>>> @@ -1638,6 +1638,8 @@ static int iproute_get(int argc, char **argv)
>>> if (req.r.rtm_family == AF_UNSPEC)
>>> req.r.rtm_family = AF_INET;
>>>
>>> + req.r.rtm_flags |= RTM_
On 9/21/15 3:19 PM, Stephen Hemminger wrote:
@@ -1638,6 +1638,8 @@ static int iproute_get(int argc, char **argv)
if (req.r.rtm_family == AF_UNSPEC)
req.r.rtm_family = AF_INET;
+ req.r.rtm_flags |= RTM_F_LOOKUP_TABLE;
+
if (rtnl_talk(&rth, &req.n, &req.n, siz
On Mon, 21 Sep 2015 11:19:48 -0700
David Ahern wrote:
> Currently 'ip route get' does not show the table the lookup result comes
> from and prior to kernel commit c36ba6603a11 the response from the kernel
> was hardcoded to the main table. From the discussion this appears to be
> a leftover from
50 matches
Mail list logo
