On 12/7/18 3:20 PM, Eric Dumazet wrote:
>
>
> On 12/07/2018 01:49 PM, David Ahern wrote:
>> From: David Ahern
>>
>> Similar to routes and rules, add protocol attribute to neighbor entries
>> for easier tracking of how each was created.
>>
>> Signe
From: David Ahern
Similar to routes and rules, add protocol attribute to neighbor entries
for easier tracking of how each was created.
Signed-off-by: David Ahern
---
include/net/neighbour.h| 2 ++
include/uapi/linux/neighbour.h | 1 +
net/core/neighbour.c | 24
On 12/4/18 3:14 AM, Shalom Toledo wrote:
> Patch #1 add string to uint conversion support for generic parameters.
> Patch #2 add string to uint support for 'fw_load_policy' generic parameter
>
> Shalom Toledo (2):
> devlink: Add string to uint{8,16,32} conversion for generic parameters
>
From: David Ahern
The existing garbage collection algorithm has a number of problems:
1. The gc algorithm will not evict PERMANENT entries as those entries
are managed by userspace, yet the existing algorithm walks the entire
hash table which means it always considers PERMANENT entries
On 12/6/18 8:59 PM, David Miller wrote:
> But why do you need the on_gc_list boolean state? f
mental blockage.
v2 coming up.
From: David Ahern
The existing garbage collection algorithm has a number of problems:
1. The gc algorithm will not evict PERMANENT entries as those entries
are managed by userspace, yet the existing algorithm walks the entire
hash table which means it always considers PERMANENT entries
From: David Ahern
Add extack messages for failures in neigh_add and neigh_delete.
Signed-off-by: David Ahern
---
net/core/neighbour.c | 55 +---
1 file changed, 39 insertions(+), 16 deletions(-)
diff --git a/net/core/neighbour.c b/net/core
On 12/5/18 5:46 PM, David Ahern wrote:
> ok. patches 5-7 are not dependent on 1-4. Should I re-send outside of
> this set?
bleh. 5 is. I'll re-send.
On 12/5/18 5:44 PM, David Miller wrote:
> From: David Ahern
> Date: Wed, 5 Dec 2018 15:34:09 -0800
>
>> @@ -270,37 +270,25 @@ static inline bool neigh_key_eq128(const struct
>> neighbour *n, const void *pkey)
>> (n32[2] ^ p32[2]) | (n32[3] ^ p32[3]))
From: David Ahern
There are no more direct callers of ___neigh_lookup_noref so no need
for it to be a standalone helper.
Signed-off-by: David Ahern
---
include/net/neighbour.h | 22 +-
1 file changed, 5 insertions(+), 17 deletions(-)
diff --git a/include/net/neighbour.h b
From: David Ahern
Consolidate calculations of the neighbor hash into a single helper.
Signed-off-by: David Ahern
---
include/net/neighbour.h | 10 +-
net/core/neighbour.c| 15 +--
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/include/net/neighbour.h
From: David Ahern
When adding a new neighbor via rtnetlink, neigh_add does a lookup
and if the result is NULL calls __neigh_lookup_errno to create a
new entry if the NLM_F_CREATE flag is set. But, __neigh_lookup_errno
calls neigh_lookup again before neigh_create; the neigh_lookup is
redundant
From: David Ahern
cleanups:
- remove open coding of key and hash functions for ipv4 and ipv6
and then collapse hash functions
- collapse now unnecessary ___neigh_lookup_noref helper
- create helper for neigh hash computation
- remove duplicate lookup in neigh_add
After that add extack
From: David Ahern
Add extack messages for failures in neigh_add and neigh_delete.
Also, require NDA_DST length to be exactly the key length for the
table otherwise it is an unexpected address and can lead to unexpected
entries. e.g., IPv4 table sent and IPv6 address (using
From: David Ahern
There are no more direct references to arp_hashfn so fold it into
arp_hash, the hash callback for arp.
Signed-off-by: David Ahern
---
include/net/arp.h | 8
net/ipv4/arp.c| 5 -
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/include/net/arp.h
From: David Ahern
There are no more direct references to ndisc_hashfn so fold it into
ndisc_hash, the hash callback for ndisc.
Signed-off-by: David Ahern
---
include/net/ndisc.h | 10 --
net/ipv6/ndisc.c| 7 ++-
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git
From: David Ahern
___neigh_lookup_noref takes the key and hash functions as inputs, yet
those are part of the operations listed in the neigh_table which is
also passed as an arugment. Remove the open coding of these internal
implementations by converting uses of ___neigh_lookup_noref
On 12/3/18 5:00 PM, David Miller wrote:
> From: Toke Høiland-Jørgensen
> Date: Mon, 03 Dec 2018 22:00:32 +0200
>
>> I wonder if it would be possible to support both the "give me user
>> normal stats" case and the "let me do whatever I want" case by a
>> combination of userspace tooling and maybe
On 12/3/18 4:58 PM, Nambiar, Amritha wrote:
> A previous version v3 of this patch was already applied to iproute2-next.
> https://patchwork.ozlabs.org/patch/998644/
>
> I think that needs to be reverted for this v6 to apply clean.
ugh. That's embarrassing. Looks like I inadvertently pushed the
On 11/27/18 3:40 PM, Amritha Nambiar wrote:
> Added support for filtering based on port ranges.
> UAPI changes have been accepted into net-next.
>
> Example:
> 1. Match on a port range:
> -
> $ tc filter add dev enp4s0 protocol ip parent :\
> prio 1 flower ip_proto
On 11/30/18 8:00 AM, Paweł Staszewski wrote:
>
> Traces attached below:
>
>
>
> [310658.536190] rcu: INFO: rcu_sched self-detected stall on CPU
> [310658.536195] rcu: 15-: (322 ticks this GP)
> idle=fca/1/0x4002 softirq=50617185/50617185 fqs=64
> [310658.536195] rcu:
On 12/3/18 2:32 AM, Lars Ekman G wrote:
>
> Hi,
>
> Kernel version; 4.19.3
>
> A multipath ipv6 route is setup;
>
> # ip -6 ro
> 1000:: proto zebra metric 20
> nexthop via 1000::1:c0a8:101 dev eth1 weight 1
> nexthop via 1000::1:c0a8:104 dev eth1 weight 1
> nexthop
On 11/30/18 5:14 PM, Peter Oskolkov wrote:
> On Fri, Nov 30, 2018 at 3:52 PM David Ahern wrote:
>>
>> On 11/30/18 4:35 PM, Peter Oskolkov wrote:
>>> Thanks, David! This is for egress only, so I'll add an appropriate
>>> check. I'll also address your other
On 12/1/18 4:14 AM, Jesper Dangaard Brouer wrote:
>>> XDP dropping a packet is completely different.
>>>
>>> stats are important. packets disappearing with no counters -- standard
>>> counters visible by standard tools -- is a user nightmare. If the
>>> agreement is for XDP drops to be in driver
On 12/1/18 4:22 AM, Jesper Dangaard Brouer wrote:
>>
>> So we should count all XDP RX packets as successful rx packets i.e
>> netdev->stats.rx_packets++; regardless of the XDP program decision ?
>
> Yes.
>
>> this implies that XDP_TX packets will be counted twice once in
>>
On 11/30/18 4:35 PM, Peter Oskolkov wrote:
> Thanks, David! This is for egress only, so I'll add an appropriate
> check. I'll also address your other comments/concerns in a v2 version
> of this patchset.
Why are you limiting this to egress only?
On 11/30/18 1:30 PM, Michael S. Tsirkin wrote:
I would like to see basic packets, bytes, and dropped counters
tracked
for Rx and Tx via the standard netdev counters for all devices.
>>
>> The problem of reporting XDP_DROP in the netedev drop counter is that
>> they don't fit this
On 11/28/18 6:34 PM, Peter Oskolkov wrote:
> On Wed, Nov 28, 2018 at 4:47 PM David Ahern wrote:
>>
>> On 11/28/18 5:22 PM, Peter Oskolkov wrote:
>>> diff --git a/net/core/filter.c b/net/core/filter.c
>>> index bd0df75dc7b6..17f3c37218e5 100644
>>>
On 11/30/18 11:12 AM, Stephen Hemminger wrote:
> I can understand why you would want this, but it is changing the
> behavior of an existing command that might be used in scripts.
+1
On 11/30/18 8:14 AM, Eric Dumazet wrote:
>
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
On 11/30/18 7:58 AM, Ido Schimmel wrote:
> Can you please share the reproducer (assuming it exists)? I don't really
> understand the fix. None of the functions you patched are in the trace.
> Also, looking at IPv4 GRE code, while GRE device has dev->addr_len set
> to 4, dev->type is set to
On 11/29/18 11:50 AM, Stephen Hemminger wrote:
> PS: ss still doesn't support JSON output, given the volume of output it would
> be good.
I thought Stefano was investigating it as an alternative to the 'display
selected columns' patches.
On 11/28/18 10:10 PM, Eric Dumazet wrote:
>
>
> On 11/28/2018 04:01 PM, Stephen Hemminger wrote:
>> On Mon, 26 Nov 2018 14:29:53 -0800
>> Eric Dumazet wrote:
>>
>>> Kernel support was added in linux-4.18 in commit feb5f2ec6464
>>> ("tcp: export packets delivery info")
>>>
>>> Tested:
>>>
>>> ss
On 11/28/18 5:22 PM, Peter Oskolkov wrote:
> diff --git a/net/core/filter.c b/net/core/filter.c
> index bd0df75dc7b6..17f3c37218e5 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -4793,6 +4793,60 @@ static int bpf_push_seg6_encap(struct sk_buff *skb,
> u32 type, void *hdr, u32 len
print library")
> Signed-off-by: Roopa Prabhu
> ---
> bridge/bridge.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: David Ahern
++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
Reviewed-by: David Ahern
On 11/27/18 11:32 PM, Jakub Kicinski wrote:
> Hi!
>
> I've been hoping for some time that someone more competent would fix
> the stack frame size warning in rtnl_newlink(), but looks like I'll
> have to take a stab at it myself :) That's the only warning I see
> in most of my builds.
Somehow my
..
>
> Signed-off-by: Jakub Kicinski
> ---
> net/core/rtnetlink.c | 313 +--
> 1 file changed, 154 insertions(+), 159 deletions(-)
Reviewed-by: David Ahern
ernet/freescale/dpaa2/dpaa2-eth.c | 189
> ++-
> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.h | 6 +
> 2 files changed, 194 insertions(+), 1 deletion(-)
>
Reviewed-by: David Ahern
On 11/26/18 9:27 AM, Ioana Ciocoi Radulescu wrote:
> Add counters for xdp processed frames to the channel statistics.
>
> Signed-off-by: Ioana Radulescu
> ---
> v2: no changes
>
Reviewed-by: David Ahern
On 11/28/18 2:18 AM, Ioana Ciocoi Radulescu wrote:
>> -Original Message-
>> From: David Miller
>> Sent: Wednesday, November 28, 2018 2:25 AM
>> To: Ioana Ciocoi Radulescu
>> Cc: netdev@vger.kernel.org; Ioana Ciornei ;
>> dsah...@gmail.com; Camelia Alexandra Groza
>> Subject: Re: [PATCH
From: David Ahern
Randy reported when CONFIG_PROC_FS is not enabled:
ld: net/ipv4/af_inet.o: in function `inet_init':
af_inet.c:(.init.text+0x42d): undefined reference to `raw_init'
Fix by moving the endif up to the end of the proc entries
Fixes: 6897445fb194c ("net: provide a s
On 11/26/18 5:41 PM, Alexis Bauvin wrote:
> Le 26 nov. 2018 à 18:54, David Ahern a écrit :
>> On 11/26/18 9:32 AM, Alexis Bauvin wrote:
>>> Thanks for the review. I’ll send a v5 if you have no other comment on
>>> this version!
>>
>> A few comments on
On 11/26/18 5:23 PM, Nambiar, Amritha wrote:
>> Can tc flower use something similar to ip ru with single port or port
>> range handled like this?
>>
>> },{
>> "priority": 32764,
>> "src": "172.16.1.0",
>> "srclen": 24,
>> "ipproto": "tcp",
>> "sport":
On 11/26/18 2:27 PM, Joe Stringer wrote:
> @@ -2405,6 +2407,9 @@ enum bpf_func_id {
> /* BPF_FUNC_perf_event_output for sk_buff input context. */
> #define BPF_F_CTXLEN_MASK(0xfULL << 32)
>
> +/* BPF_FUNC_sk_lookup_tcp and BPF_FUNC_sk_lookup_udp flags. */
> +#define
On 11/26/18 12:06 PM, Alexis Bauvin wrote:
> Moreover, the issue of mixing default and non-default vrf needs to be
> addressed. For now it is stale, as I don’t see any solution (except for
> rewriting the whole thing as you suggested before) to address the
> "Address already in use" made by a
On 11/26/18 9:32 AM, Alexis Bauvin wrote:
> Thanks for the review. I’ll send a v5 if you have no other comment on
> this version!
A few comments on the test script; see attached which has the changes.
Mainly the cleanup does not need to be called at the end since you setup
the exit trap. The
On 11/24/18 6:44 PM, Eric Dumazet wrote:
> Signed-off-by: Eric Dumazet
> ---
> man/man8/tc-fq.8 | 37 ++---
> 1 file changed, 26 insertions(+), 11 deletions(-)
>
applied to iproute2-next. Thanks, Eric.
On 11/24/18 6:25 PM, David Miller wrote:
> From: David Ahern
> Date: Sat, 24 Nov 2018 17:12:48 -0700
>
>> IPX was moved to staging at the end of last year. Can decnet follow
>> suit? git log seems to indicate no active development in a very long time.
>
> Last time
IPX was moved to staging at the end of last year. Can decnet follow
suit? git log seems to indicate no active development in a very long time.
David
On 11/23/18 9:56 AM, Ioana Ciocoi Radulescu wrote:
> @@ -215,6 +255,7 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
> struct dpaa2_fas *fas;
> void *buf_data;
> u32 status = 0;
> + u32 xdp_act;
>
> /* Tracing point */
>
onvert nsids.
>
> Signed-off-by: Nicolas Dichtel
> ---
> include/uapi/linux/net_namespace.h | 1 +
> net/core/net_namespace.c | 31 --
> 2 files changed, 26 insertions(+), 6 deletions(-)
>
Reviewed-by: David Ahern
On 11/23/18 11:37 PM, Eric Dumazet wrote:
> Kernel commit 48872c11b772 ("net_sched: sch_fq: add dctcp-like marking")
> added support for TCA_FQ_CE_THRESHOLD attribute.
>
> This patch adds iproute2 support for it.
>
> It also makes sure fq_print_xstats() can deal with smaller tc_fq_qd_stats
>
On 11/19/18 4:03 PM, Jakub Kicinski wrote:
> Hi!
>
> This set brings GRED support up to date with recent kernel changes.
> In particular the new netlink attributes for more fine-grained stats
> and per-virtual queue flags.
>
> To make GRED usable in modern deployments the patch set starts with
>
che
> ---
> drivers/net/vxlan.c | 32 +--
> .../selftests/net/test_vxlan_under_vrf.sh | 90 +++
> 2 files changed, 114 insertions(+), 8 deletions(-)
> create mode 100755 tools/testing/selftests/net/test_vxlan_under_vrf.sh
>
Reviewed-by: David Ahern
Thanks for adding the test case; I'll try it out next week (after the
holidays).
On 11/21/18 6:07 PM, Alexis Bauvin wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 93243479085f..12459036d0da 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -7225,6 +7225,23 @@ void netdev_lower_state_changed(struct net_device
> *lower_dev,
> }
>
ly resolve the l3mdev of eth0 to vrf-blue.
>
> Signed-off-by: Alexis Bauvin
> Reviewed-by: Amine Kherbouche
> Tested-by: Amine Kherbouche
> ---
> include/net/l3mdev.h | 22 ++
> net/l3mdev/l3mdev.c | 18 ++
> 2 files changed, 40 insertions(+)
>
Reviewed-by: David Ahern
vin
> Reviewed-by: Amine Kherbouche
> Tested-by: Amine Kherbouche
> ---
> include/net/udp_tunnel.h | 1 +
> net/ipv4/udp_tunnel.c | 10 ++
> net/ipv6/ip6_udp_tunnel.c | 9 +
> 3 files changed, 20 insertions(+)
Reviewed-by: David Ahern
On 11/22/18 1:26 AM, Toke Høiland-Jørgensen wrote:
> Saeed Mahameed writes:
>
I'd say it sounds reasonable to include XDP in the normal traffic
counters, but having the detailed XDP-specific counters is quite
useful
as well... So can't we do both (for all drivers)?
>>
>>
On 11/21/18 5:53 PM, Toshiaki Makita wrote:
>> We really need consistency in the counters and at a minimum, users
>> should be able to track packet and byte counters for both Rx and Tx
>> including XDP.
>>
>> It seems to me the Rx and Tx packet, byte and dropped counters returned
>> for the
On 11/22/18 8:50 AM, Nicolas Dichtel wrote:
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index dd25fb22ad45..25030e0317a2 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -745,6 +745,8 @@ struct net_fill_args {
> int flags;
> int
/core/net_namespace.c | 86 ++
> 2 files changed, 76 insertions(+), 11 deletions(-)
Reviewed-by: David Ahern
ed from an other netns.
>
> Signed-off-by: Nicolas Dichtel
> ---
> net/core/net_namespace.c | 5 +
> 1 file changed, 5 insertions(+)
>
Reviewed-by: David Ahern
> 1 file changed, 34 insertions(+), 14 deletions(-)
>
Reviewed-by: David Ahern
d, 4 insertions(+), 6 deletions(-)
>
Reviewed-by: David Ahern
On 11/21/18 5:54 PM, Alexis Bauvin wrote:
>>> There is one issue I can see with SO_REUSEPORT (if my understanding of it is
>>> correct). From what I understood, enabling this option will balance incoming
>>> connections (for TCP) / dgrams (for UDP) based on a 4-tuple hash (sip, dip,
>>> sport,
On 11/20/18 11:17 PM, Amritha Nambiar wrote:
> diff --git a/tc/f_flower.c b/tc/f_flower.c
> index 65fca04..722647d 100644
> --- a/tc/f_flower.c
> +++ b/tc/f_flower.c
> @@ -494,6 +494,68 @@ static int flower_parse_port(char *str, __u8 ip_proto,
> return 0;
> }
>
> +static int
On 11/21/18 2:01 PM, Nicolas Dichtel wrote:
> Le 21/11/2018 à 19:09, David Ahern a écrit :
>> On 11/21/18 4:01 AM, Nicolas Dichtel wrote:
>>> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
>>> index 92730905886c..fc568cd0b560 100644
>>> ---
On 11/21/18 1:58 PM, Nicolas Dichtel wrote:
> The target-nsid is not stored in net_cb (not needed). ref_net is set only if
> tgt_net comes from TARGET_NSID. I can add a comment.
ref_net is added by this patch and it is only used (unless I missed
something) to know if the put_net is needed. ie/,
Paweł ran some more XDP tests yesterday and from it found a couple of
issues. One is a panic in the mlx5 driver unloading the bpf program
(mlx5e_xdp_xmit); he will send a send a separate email for that problem.
The problem I wanted to discuss here is statistics for XDP context. The
short of it is
On 11/21/18 7:05 AM, Alexis Bauvin wrote:
> Le 20 nov. 2018 à 18:09, David Ahern a écrit :
>> On 11/20/18 9:58 AM, Alexis Bauvin wrote:
>>> A socket bound to vrf-blue listens on *:4789, thus owning the port. If
>>> moving an
>>> underlay to the default vrf (
On 11/21/18 6:30 AM, Alexis Bauvin wrote:
> Le 20 nov. 2018 à 22:45, David Ahern a écrit :
>>
>> On 11/20/18 7:23 AM, Alexis Bauvin wrote:
>>> We are trying to isolate the VXLAN traffic from different VMs with VRF as
>>&g
On 11/21/18 4:01 AM, Nicolas Dichtel wrote:
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 92730905886c..fc568cd0b560 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -740,7 +740,7 @@ static int rtnl_net_get_size(void)
> }
>
> static int
On 11/21/18 4:01 AM, Nicolas Dichtel wrote:
> static int rtnl_net_dumpid(struct sk_buff *skb, struct netlink_callback *cb)
> {
> - struct net *net = sock_net(skb->sk);
> struct rtnl_net_dump_cb net_cb = {
> - .net = net,
> + .tgt_net = sock_net(skb->sk),
>
On 11/20/18 2:05 AM, Nicolas Dichtel wrote:
> Le 20/11/2018 à 00:46, David Ahern a écrit :
> [snip]
>> That revelation shows another hole:
>> $ ip netns add foo
>> $ ip netns set foo 0x
> It also works with 0xf000 ...
>
>> $ ip netns list
>>
On 11/20/18 9:59 PM, Nambiar, Amritha wrote:
> Oops, submitted the v2 patch for man changes too soon, without seeing
> this. So, in this case, should I re-submit the iproute2-flower patch
> that was accepted removing the 'range' keyword?
I think so. Consistency across commands is a good thing.
On 11/20/18 9:44 PM, Nambiar, Amritha wrote:
> On 11/20/2018 2:56 PM, David Ahern wrote:
>> On 11/15/18 5:55 PM, Amritha Nambiar wrote:
>>> Add details explaining filtering based on port ranges.
>>>
>>> Signed-off-by: Amritha Nambiar
>>> ---
>>
On 11/19/18 6:40 PM, Jakub Kicinski wrote:
> On Mon, 19 Nov 2018 17:18:42 -0800, Stephen Hemminger wrote:
>>> void jsonw_hu_field(json_writer_t *self, const char *prop, unsigned short
>>> num)
>>> {
>>> jsonw_name(self, prop);
>>
>> Do you really need this? it turns out that because of C
On 11/15/18 5:55 PM, Amritha Nambiar wrote:
> Added support for filtering based on port ranges.
> UAPI changes have been accepted into net-next.
>
> Example:
> 1. Match on a port range:
> -
> $ tc filter add dev enp4s0 protocol ip parent :\
> prio 1 flower ip_proto
On 11/15/18 5:55 PM, Amritha Nambiar wrote:
> Add details explaining filtering based on port ranges.
>
> Signed-off-by: Amritha Nambiar
> ---
> man/man8/tc-flower.8 | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/man/man8/tc-flower.8
On 11/15/18 3:36 PM, Stephen Hemminger wrote:
> Several functions only used inside utils.c
>
> Signed-off-by: Stephen Hemminger
> ---
> rdma/rdma.h | 11 ---
> rdma/utils.c | 12 ++--
> 2 files changed, 6 insertions(+), 17 deletions(-)
>
this patch breaks builds for me on
On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> We are trying to isolate the VXLAN traffic from different VMs with VRF as
> shown
> in the schemas below:
>
> +-+ ++
> | +--+| | ++ |
> | | |
On 11/20/18 9:58 AM, Alexis Bauvin wrote:
> A socket bound to vrf-blue listens on *:4789, thus owning the port. If moving
> an
> underlay to the default vrf (ip link set dummy-b nomaster), a new socket will
> be
> created, unbound to any interface and listening on *:4789. However, because it
>
On 11/20/18 9:27 AM, Alexis Bauvin wrote:
> maybe even move
> the function to net/core/dev.c, with other master-related functions.
> What do you think?
yes, it is a generic function.
On 11/20/18 8:48 AM, David Ahern wrote:
> On 11/20/18 8:35 AM, Roopa Prabhu wrote:
>> On Tue, Nov 20, 2018 at 7:04 AM David Ahern wrote:
>>>
>>> On 11/20/18 7:23 AM, Alexis Bauvin wrote:
>>>> When underlay VRF changes, either because the lower device
On 11/20/18 8:35 AM, Roopa Prabhu wrote:
> On Tue, Nov 20, 2018 at 7:04 AM David Ahern wrote:
>>
>> On 11/20/18 7:23 AM, Alexis Bauvin wrote:
>>> When underlay VRF changes, either because the lower device itself changed,
>>> or its VRF changed, this patch release
On 11/20/18 2:05 AM, Nicolas Dichtel wrote:
> Le 20/11/2018 à 00:46, David Ahern a écrit :
> [snip]
>> That revelation shows another hole:
>> $ ip netns add foo
>> $ ip netns set foo 0x
> It also works with 0xf000 ...
yes, I realized last night I sent
On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> When underlay VRF changes, either because the lower device itself changed,
> or its VRF changed, this patch releases the current socket of the VXLAN
> device and recreates another one in the right VRF. This allows for
> on-the-fly change of the underlay
On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> Creating a VXLAN device with is underlay in the non-default VRF makes
> egress route lookup fail or incorrect since it will resolve in the
> default VRF, and ingress fail because the socket listens in the default
> VRF.
>
> This patch binds the
On 11/20/18 7:23 AM, Alexis Bauvin wrote:
> We are trying to isolate the VXLAN traffic from different VMs with VRF as
> shown
> in the schemas below:
>
> +-+ ++
> | +--+| | ++ |
> | | |
On 11/19/18 7:16 PM, David Miller wrote:
> From: Xin Long
> Date: Thu, 15 Nov 2018 16:23:38 +0900
>
>> The attachment is the ip6_dst.sh with IPVS.
>>
>> # sh ip6_dst.sh
>
> Maybe a selftests candidate?
>
That script was not a reliable reproducer for me.
I created a much simpler one that
On 11/19/18 2:59 PM, Joe Stringer wrote:
> @@ -2221,12 +,13 @@ union bpf_attr {
> * **sizeof**\ (*tuple*\ **->ipv6**)
> * Look for an IPv6 socket.
> *
> - * If the *netns* is zero, then the socket lookup table in the
> - * netns
On 11/9/18 5:06 PM, David Ahern wrote:
> On 11/9/18 9:21 AM, David Ahern wrote:
>>> Is there possible to add only counters from xdp for vlans ?
>>> This will help me in testing.
>> I will take a look today at adding counters that you can dump using
>> bpftool
On 11/19/18 12:47 PM, Joe Stringer wrote:
> On Mon, 19 Nov 2018 at 10:39, David Ahern wrote:
>>
>> On 11/19/18 11:36 AM, Joe Stringer wrote:
>>> Hi David, thanks for pointing this out.
>>>
>>> This is more of an oversight through iterations, the run
On 11/19/18 11:36 AM, Joe Stringer wrote:
> Hi David, thanks for pointing this out.
>
> This is more of an oversight through iterations, the runtime lookup
> will fail to find a socket if the netns value is greater than the
> range of a uint32 so I think it would actually make more sense to drop
On 11/19/18 7:21 AM, Alexis Bauvin wrote:
> UDP tunnel sockets are always opened unbound to a specific device. This
> patch allow the socket to be bound on a custom device, which
> incidentally makes UDP tunnels VRF-aware if binding to an l3mdev.
>
> Signed-off-by: Alexis Bauvin
> Reviewed-by:
Hi Joe:
The netns_id to the bpf_sk_lookup_{tcp,udp} functions in
net/core/filter.c is a u64, yet the APIs in include/uapi/linux/bpf.h
shows a u32. Is that intentional or an oversight through the iterations?
David
From: David Ahern
Preethi reported that PMTU discovery for UDP/raw applications is not
working in the presence of VRF when the socket is not bound to a device.
The problem is that ip6_sk_update_pmtu does not consider the L3 domain
of the skb device if the socket is not bound. Update the function
On 11/11/18 7:25 PM, Md. Islam wrote:
> This patch implements SAIL[1] based routing table lookup for XDP. I
> however made some changes from the original proposal (details are
> described in the patch). This changes decreased the memory consumption
> from 21.94 MB to 4.97 MB for my example routing
On 11/15/18 3:36 PM, Stephen Hemminger wrote:
> Code cleanup including:
>* make local functions static
>* drop dead code
>* whitespace code style cleanup
>
Hi Stephen:
You did not mark these for -next but that is typically where cleanups
go. What is your intention?
1 - 100 of 3466 matches
Mail list logo
