在 2019/7/9 18:42, Florian Westphal 写道:
> wenxu wrote:
>>> For NAT on bridge, it should be possible already to push such packets
>>> up the stack by
>>>
>>> bridge input meta iif eth0 ip saddr 192.168.0.0/16 \
>>>meta pkttype set unicast
From: wenxu
[ 697.665184] BUG: kernel NULL pointer dereference, address: 0030
[ 697.665550] #PF: supervisor read access in kernel mode
[ 697.665906] #PF: error_code(0x) - not-present page
[ 697.666297] PGD 80104e636067 P4D 80104e636067 PUD ff4b02067 PMD 0
From: wenxu
[ 3444.666552] BUG: kernel NULL pointer dereference, address:
[ 3444.31] #PF: supervisor read access in kernel mode
[ 3444.666701] #PF: error_code(0x) - not-present page
[ 3444.666769] PGD 800812dd7067 P4D 800812dd7067 PUD 8207cc067 PMD 0
在 2019/7/11 2:25, Vlad Buslov 写道:
> Recent refactoring of tc block offloads infrastructure introduced new
> flow_block_cb_setup_simple() method intended to be used as unified way for
> all drivers to register offload callbacks. However, commit that actually
> extended all users (drivers) with blo
From: wenxu
The flow_cls_common_offload prio should be not zero
It leads the invalid table prio in hw.
# nft add table netdev firewall
# nft add chain netdev firewall acl { type filter hook ingress device
mlx_pf0vf0 priority - 300 \; }
# nft add rule netdev firewall acl ip daddr 1.1.1.7 drop
On 8/12/2019 10:11 PM, Vlad Buslov wrote:
>
>> +static void flow_block_ing_cmd(struct net_device *dev,
>> + flow_indr_block_bind_cb_t *cb,
>> + void *cb_priv,
>> + enum flow_block_command command)
>> +{
>> +struct f
From: wenxu
For receive side the standby, primary and failover is the same one,
If the packet receive from standby or primary should can be deliver
to failover dev.
For example: there are VF and virtio device failover together.
When live migration the VF detached and send/recv packet through
From: wenxu
ip l add dev tun type gretap key 1000
Non-tunnel-dst ip tunnel device can send packet through lwtunnel.
This patch provide the tun_info dst cache support for this mode
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 25 -
1 file changed, 20 insertions
From: wenxu
The lwtunnel_state is not init the dst_cache Which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel_core.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/net
From: wenxu
The lwtunnel_state is not init the dst_cache Which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel_core.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/net
From: wenxu
ip l add dev tun type gretap key 1000
Non-tunnel-dst ip tunnel device can send packet through lwtunnel
This patch provide the tun_inf dst cache support for this mode.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 38 +++---
1 file changed, 27
From: wenxu
Current fib_multipath_hash_policy can make hash based on the L3 or
L4. But it only work on the outer IP. So a specific tunnel always
has the same hash value. But a specific tunnel may contain so many
inner connection. However there is no good ways for tunnel packet.
A specific tunnel
On 2/22/2019 11:39 AM, David Ahern wrote:
> On 2/21/19 10:00 PM, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> The lwtunnel_state is not init the dst_cache Which make the
>> ip_md_tunnel_xmit can't use the dst_cache. It will lookup
>> route table eve
From: wenxu
The metadata_dst is not init the dst_cache which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/sched/act_tunnel_key.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
From: wenxu
The metadata_dst is not init the dst_cache which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/netfilter/nft_tunnel.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/net/netfilter/nft_tun
From: wenxu
Current fib_multipath_hash_policy can make hash based on the L3 or
L4. But it only work on the outer IP. So a specific tunnel always
has the same hash value. But a specific tunnel may contain so many
inner connections. However there is no good way for tunnel packet.
A specific tunnel
On 2019/2/22 下午6:26, Nikolay Aleksandrov wrote:
> On 22/02/2019 11:20, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> Current fib_multipath_hash_policy can make hash based on the L3 or
>> L4. But it only work on the outer IP. So a specific tunnel always
>> has th
On 2019/2/22 下午11:03, David Ahern wrote:
> On 2/21/19 11:14 PM, wenxu wrote:
>> build_state in the rcu_read_lock and disable the preempt
>>
>> rcu_read_lock();
>> ops = rcu_dereference(lwtun_encaps[encap_type]);
>> if (likely(ops && ops-
From: wenxu
The lwtunnel_state is not init the dst_cache Which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/core/lwtunnel.c | 3 ++-
net/ipv4/ip_tunnel_core.c | 20
2 files change
On 2019/2/23 上午12:08, Nikolay Aleksandrov wrote:
> On 22/02/2019 14:50, wenxu wrote:
>> On 2019/2/22 下午6:26, Nikolay Aleksandrov wrote:
>>> On 22/02/2019 11:20, we...@ucloud.cn wrote:
>>>> From: wenxu
>>>>
>>>> Current fib_multipath_hash_p
From: wenxu
The lwtunnel_state is not init the dst_cache Which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu
---
net/core/lwtunnel.c | 16
net/ipv4/ip_tunnel_core.c | 18 ++
2
From: wenxu
Current fib_multipath_hash_policy can make hash based on the L3 or
L4. But it only work on the outer IP. So a specific tunnel always
has the same hash value. But a specific tunnel may contain so many
inner connections.
This patch provide a generic multipath_hash in floi_common. It
From: wenxu
ip l add dev tun type gretap key 1000
Non-tunnel-dst ip tunnel device can send packet through lwtunnel
This patch provide the tun_inf dst cache support for this mode.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 38 +++---
1 file changed, 27
From: wenxu
Current fib_multipath_hash_policy can make hash based on the L3 or
L4. But it only work on the outer IP. So a specific tunnel always
has the same hash value. But a specific tunnel may contain so many
inner connections.
This patch provide a generic multipath_hash in floi_common. It
d-off-by: Ido Schimmel
> Cc: wenxu
> ---
> net/ipv4/route.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index 7cf4c8305071..e3ac458b5d8b 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@
From: wenxu
dst_cache_destroy will be called in dst_release
dst_release-->dst_destroy_rcu-->dst_destroy-->metadata_dst_free
-->dst_cache_destroy
It should not call dst_cache_destroy before dst_release
Fixes: 41411e2fd6b8 ("net/sched: act_tunnel_key: Add dst_cache suppor
From: wenxu
dst_cache_destroy will be called in dst_release
dst_release-->dst_destroy_rcu-->dst_destroy-->metadata_dst_free
-->dst_cache_destroy
It should not call dst_cache_destroy before dst_release
Fixes: 41411e2fd6b8 ("net/sched: act_tunnel_key: Add dst_cache suppor
From: wenxu
There is currently no support for the multicasti/broadcst aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb of vxlan devcice. In
this mode the
On 2019/3/23 下午3:50, Pravin Shelar wrote:
> On Thu, Mar 21, 2019 at 3:34 AM wrote:
>> From: wenxu
>>
>> There is currently no support for the multicasti/broadcst aspects
>> of VXLAN in ovs. In the datapath flow the tun_dst must specific.
>> But in the IP_TUNNEL
On 2019/3/23 下午3:50, Pravin Shelar wrote:
>
>> diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c
>> index 691da85..033df5c 100644
>> --- a/net/openvswitch/flow_netlink.c
>> +++ b/net/openvswitch/flow_netlink.c
>> @@ -403,6 +403,7 @@ size_t ovs_key_attr_size(void)
>>
From: wenxu
There is currently no support for the multicast/broadcast aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb table of vxlan devcice. In
this mode
On 2019/3/24 上午5:39, Pravin Shelar wrote:
> On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote:
>> On 2019/3/23 下午3:50, Pravin Shelar wrote:
>>
>> On Thu, Mar 21, 2019 at 3:34 AM wrote:
>>
>> From: wenxu
>>
>> There is currently no support for the multicast
On 2019/3/25 上午2:46, Pravin Shelar wrote:
> On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote:
>> On 2019/3/24 上午5:39, Pravin Shelar wrote:
>>> On Sat, Mar 23, 2019 at 2:18 AM wenxu wrote:
>>>> On 2019/3/23 下午3:50, Pravin Shelar wrote:
>>>>
>>>>
On 3/25/2019 9:47 AM, Tonghao Zhang wrote:
> On Mon, Mar 25, 2019 at 9:24 AM wenxu wrote:
>> On 2019/3/25 上午2:46, Pravin Shelar wrote:
>>> On Sun, Mar 24, 2019 at 12:03 AM wenxu wrote:
>>>> On 2019/3/24 上午5:39, Pravin Shelar wrote:
>>>>> On Sat, Ma
From: wenxu
There is currently no support for the multicast/broadcast aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb table of vxlan devcice. In
this mode
From: wenxu
There is currently no support for the multicast/broadcast aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb table of vxlan devcice. In
this mode
From: wenxu
When register indr block for vlan device, it should check the real_dev
of vlan device is same as uplink device. Or it will set offload rule
to mlx5e which will never hit.
Signed-off-by: wenxu
---
drivers/net/ethernet/mellanox/mlx5/core/en_rep.c | 2 +-
1 file changed, 1 insertion
From: wenxu
The mlx5e support the lag mode. When add mlx_p0 and mlx_p1 to bond0.
packet received from mlx_p0 or mlx_p1 and in the ingress tc flower
forward to vf0. The tc rule can't be offloaded for the non indr
rejistor block for the bonding device.
Signed-off-by: wenxu
---
driver
From: wenxu
The mlx5e support the lag mode. When add mlx_p0 and mlx_p1 to bond0.
packet received from mlx_p0 or mlx_p1 and in the ingress tc flower
forward to vf0. The tc rule can't be offloaded because there is
no indr_register_block for the bonding device.
Signed-off-by: wenxu
---
dr
There will be multiple vlan device which maybe not belong to the uplink rep
device, so wen can limit it
在 2019/5/18 4:30, Saeed Mahameed 写道:
> On Wed, 2019-05-15 at 17:25 +0800, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> When register indr block for vlan device, it should
在 2019/5/18 6:11, Mark Bloch 写道:
>
> On 5/17/19 2:17 AM, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> The mlx5e support the lag mode. When add mlx_p0 and mlx_p1 to bond0.
>> packet received from mlx_p0 or mlx_p1 and in the ingress tc flower
>> forward to
From: wenxu
The mlx5e support the lag mode. When add mlx_p0 and mlx_p1 to bond0.
packet received from mlx_p0 or mlx_p1 and in the ingress tc flower
forward to vf0. The tc rule can't be offloaded because there is
no indr_register_block for the bonding device.
Signed-off-by: wenxu
---
dr
lx_pf0vf0, the
outgoing pf is mlx_p1. Althrough the tc flower rule show in_hw
I check with the driver both mlx_pf0vf0 and peer(mlx_p1) install the tc rule
success
I think it's a problem of lag mode. Or I miss some configureation?
BR
wenxu
From: wenxu
There is currently no support for the multicast/broadcast aspects
of VXLAN in ovs. In the datapath flow the tun_dst must specific.
But in the IP_TUNNEL_INFO_BRIDGE mode the tun_dst can not be specific.
And the packet can forward through the fdb table of vxlan devcice. In
this mode
From: wenxu
When openvswitch conntrack offload with act_ct action. Fragment packets
defrag in the ingress tc act_ct action and miss the next chain. Then the
packet pass to the openvswitch datapath without the mru. The over
mtu packet will be dropped in output action in openvswitch for over mtu
struct bpf_skb_data_end *cb = (struct bpf_skb_data_end *)skb->cb;
BUILD_BUG_ON(sizeof(*cb) > sizeof_field(struct sk_buff, cb));
cb->data_meta = skb->data - skb_metadata_len(skb);
cb->data_end = skb->data + skb_headlen(skb);
}
It seems no space for new value add before 'data'?
BR
wenxu
From: wenxu
When openvswitch conntrack offload with act_ct action. Fragment packets
defrag in the ingress tc act_ct action and miss the next chain. Then the
packet pass to the openvswitch datapath without the mru. The over
mtu packet will be dropped in output action in openvswitch for over mtu
-test: yes
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes
# ethtool -K net3 | grep tls-hw
tls-hw-tx-offload: on
tls-hw-rx-offload: off [fixed]
I found the rx offload is not supported currently?
BR
wenxu
From: wenxu
When openvswitch conntrack offload with act_ct action. Fragment packets
defrag in the ingress tc act_ct action and miss the next chain. Then the
packet pass to the openvswitch datapath without the mru. The defrag over
mtu packet will be dropped in output of openvswitch for over mtu
Hi paulb & Pravin,
Could you review for this patch> Thanks.
BR
wenxu
On 7/21/2020 11:09 AM, we...@ucloud.cn wrote:
> From: wenxu
>
> When openvswitch conntrack offload with act_ct action. Fragment packets
> defrag in the ingress tc act_ct action and miss the next chain
On 7/16/2020 5:17 AM, Florian Westphal wrote:
> Jakub Kicinski wrote:
>> On Tue, 7 Jul 2020 12:55:08 +0800 we...@ucloud.cn wrote:
>>> From: wenxu
>>>
>>> Add nf_ct_frag_gather and Make nf_ct_frag6_gather elide the CB clear
>>> when packets are
From: wenxu
The fragment packets do defrag in tcf_ct_handle_fragments
will clear the skb->cb which make the qdisc_skb_cb clear
too. So the qdsic_skb_cb should be store before defrag and
restore after that.
It also update the pkt_len after all the
fragments finish the defrag to one packet
在 2020/7/18 20:30, Florian Westphal 写道:
> we...@ucloud.cn wrote:
>> From: wenxu
>>
>> The fragment packets do defrag in tcf_ct_handle_fragments
>> will clear the skb->cb which make the qdisc_skb_cb clear
>> too. So the qdsic_skb_cb should be store before def
From: wenxu
The fragment packets do defrag in tcf_ct_handle_fragments
will clear the skb->cb which make the qdisc_skb_cb clear
too. So the qdsic_skb_cb should be store before defrag and
restore after that.
It also update the pkt_len after all the
fragments finish the defrag to one packet
From: wenxu
The fragment packets do defrag in tcf_ct_handle_fragments
will clear the skb->cb which make the qdisc_skb_cb clear
too. So the qdsic_skb_cb should be store before defrag and
restore after that.
It also update the pkt_len after all the
fragments finish the defrag to one packet
From: wenxu
The fragment packets do defrag in act_ct module. If the reassembled
packet should send out to another net device. This over mtu big packet
should be fragmented to send out. This patch add the act ct_output to
archive this.
Signed-off-by: wenxu
---
include/net/tc_act/tc_ct_output.h
> +static DEFINE_PER_CPU(unsigned int, ct_output_rec_level);
> Wenxu, first of all, thanks for doing this.
>
> Hopefully this helps to show how much duplicated code this means.
> Later on, any bug that we find on mirrer, we also need to fix in
> act_ct_output, which is not good.
&g
From: wenxu
Add ipv6_fragment to ipv6_stub to avoid calling netfilter when
access ip6_fragment.
Signed-off-by: wenxu
---
include/net/ipv6_stubs.h | 3 +++
net/ipv6/af_inet6.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/include/net/ipv6_stubs.h b/include/net/ipv6_stubs.h
index
From: wenxu
Add ip6_fragment in ipv6_stub and use it in openvswitch
wenxu (2):
ipv6: add ipv6_fragment hook in ipv6_stub
openvswitch: using ip6_fragment in ipv6_stub
include/net/ipv6_stubs.h | 2 ++
net/ipv6/af_inet6.c | 1 +
net/openvswitch/actions.c | 6 ++
3 files changed, 5
From: wenxu
Using ipv6_stub->ipv6_fragment to avoid the netfilter dependency
Signed-off-by: wenxu
---
net/openvswitch/actions.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 2611657..1f3d406 100644
--
Thu, Aug 27, 2020 at 07:51:47AM -0700, David Miller wrote:
>> From: we...@ucloud.cn
>> Date: Thu, 27 Aug 2020 18:39:51 +0800
>>
>>> From: wenxu
>>>
>>> Add ipv6_fragment to ipv6_stub to avoid calling netfilter when
>>> access ip6_fragment.
>&
From: wenxu
Add ip6_fragment in ipv6_stub and use it in openvswitch
This version add default function eafnosupport_ipv6_fragment
wenxu (2):
ipv6: add ipv6_fragment hook in ipv6_stub
openvswitch: using ip6_fragment in ipv6_stub
include/net/ipv6_stubs.h | 3 +++
net/ipv6/addrconf_core.c
From: wenxu
Add ipv6_fragment to ipv6_stub to avoid calling netfilter when
access ip6_fragment.
Signed-off-by: wenxu
---
v2: add default one eafnosupport_ipv6_fragment
include/net/ipv6_stubs.h | 3 +++
net/ipv6/addrconf_core.c | 8
net/ipv6/af_inet6.c | 1 +
3 files changed, 12
From: wenxu
Using ipv6_stub->ipv6_fragment to avoid the netfilter dependency
Signed-off-by: wenxu
---
net/openvswitch/actions.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 2611657..fd34089 100644
--
From: wenxu
In the forward chain the iif is changed from slave device to master vrf
device. It will lead the offload not match on lower slave device.
This patch the flow table iif and oif based on route cache dst->dev, not
the skb->iif
This patch make the flollowing example can work c
Hi David,
This patch status shows Deferred. Should I resubmit it?
wenxu
On 2018/12/27 下午5:31, we...@ucloud.cn wrote:
> From: wenxu
>
> ip l add dev tun type gretap key 1000
> ip a a dev tun 10.0.0.1/24
>
> Packets with tun-id 1000 can be recived by tun dev. But packet can&#
On 2018/12/28 下午10:42, David Ahern wrote:
> On 12/27/18 2:38 AM, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> In the ip_rcv the skb go through the PREROUTING hook first,
>> Then jump in vrf device go through the same hook again.
>> When conntrack work with vrf
From: wenxu
In the forward chain the iif is changed from slave device to master vrf
device. It will lead the offload not match on lower slave device.
This patch the flow table iif and oif based on route cache dst->dev, not
the skb->iif
This patch make the flollowing example can work c
On 1/11/2019 2:15 AM, Pablo Neira Ayuso wrote:
> On Thu, Jan 10, 2019 at 01:16:08PM +0800, we...@ucloud.cn wrote:
> [...]
>> +static struct xt_match tunnel_mt_reg __read_mostly = {
>> +.name = "tunnel",
>> +.revision = 0,
>> +.family = NFPROTO_UNSPEC,
>> +.
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
From: wenxu
ip l add dev tun type gretap key 1000
ip a a dev tun 10.0.0.1/24
Packets with tun-id 1000 can be recived by tun dev. But packet can't
be sent through dev tun for non-tunnel-dst
With this patch: tunnel-dst can be get through lwtunnel like beflow:
ip r a 10.0.0.7 encap ip id 100
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
On 2019/1/15 下午7:17, Florian Westphal wrote:
> we...@ucloud.cn wrote:
>> From: wenxu
>> so with this patch userspace can add the 'don't re-do entire ruleset for
>> vrf' policy
>> itself like the following
>>
>> nft add rule firewall rules-
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
From: wenxu
In the ip_rcv the skb go through the PREROUTING hook first,
Then jump in vrf device go through the same hook again.
When conntrack dnat work with vrf, there will be some conflict for rules.
Because the package go through the hook twice with different nf status
ip link add user1 type
Hi David,
what about the status of this patch?
BR
wenxu
On 2019/1/15 上午10:44, we...@ucloud.cn wrote:
> From: wenxu
>
> ip l add dev tun type gretap key 1000
> ip a a dev tun 10.0.0.1/24
>
> Packets with tun-id 1000 can be recived by tun dev. But packet can't
> be se
From: wenxu
Fixes: 862a03c ("gre: refactor the gre_fb_xmit")
1a66a83 ("gre: add collect_md mode to ERSPAN tunnel")
Signed-off-by: wenxu
---
net/ipv4/ip_gre.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip
On 2019/1/18 下午10:18, Pablo Neira Ayuso wrote:
> On Thu, Jan 10, 2019 at 01:16:08PM +0800, we...@ucloud.cn wrote:
>> From: wenxu
>>
>> This patch allows us to match on the tunnel metadata that is available
>> of the packet. We can use this to validate if the packet c
From: wenxu
ip l add dev tun type gretap key 1000
ip a a dev tun 10.0.0.1/24
Packets with tun-id 1000 can be recived by tun dev. But packet can't
be sent through dev tun for non-tunnel-dst
With this patch: tunnel-dst can be get through lwtunnel like beflow:
ip r a 10.0.0.7 encap i
Hi stephen & David,
The status of this patch shows "Accepted' for long time.
http://patchwork.ozlabs.org/patch/1019880/
But it doesn't applied to master. There are some other problem for this patch?
BR
wenxu
On 1/2/2019 11:57 AM, we...@ucloud.cn wrote:
> From: wenxu
From: wenxu
Init the gre_key from tuninfo->key.tun_id and init the mark
from the skb->mark, set the oif zero in the collect metadata mode
Fixes: cfc7381 ("ip_tunnel: add collect_md mode to IPIP tunnel'")
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 5 +++--
1 file
From: wenxu
This patchset add tunnel_dst_cache and tnl_update_pmtu feature for
ip_md_tunnel_xmit also bugfix. Then Refactor collect metatdata mode
tunnel xmit to ip_md_tunnel_xmit
wenxu (4):
ip_tunnel: Add ip tunnel dst_cache in ip_md_tunnel_xmit
ip_tunnel: Add tnl_update_pmtu in
From: wenxu
Refactor collect metatdata mode tunnel xmit to the generic xmit function
ip_md_tunnel_xmit. It makes codes more generic and support more feture
such as pmtu_update through ip_md_tunnel_xmit
Signed-off-by: wenxu
---
net/ipv4/ip_gre.c | 112
From: wenxu
Add ip tunnel dst cache in ip_md_tunnel_xmit to make more
efficient for the route lookup.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index
From: wenxu
Add tnl_update_pmtu in ip_md_tunnel_xmit to dynamic modify
the pmtu which packet send through collect_metadata mode
ip tunnel
Signed-off-by: wenxu
---
include/net/ip_tunnels.h | 2 +-
net/ipv4/ip_tunnel.c | 37 +++--
net/ipv4/ipip.c
From: wenxu
Add tnl_update_pmtu in ip_md_tunnel_xmit to dynamic modify
the pmtu which packet send through collect_metadata mode
ip tunnel
Signed-off-by: wenxu
---
include/net/ip_tunnels.h | 2 +-
net/ipv4/ip_tunnel.c | 37 +++--
net/ipv4/ipip.c
From: wenxu
Init the gre_key from tuninfo->key.tun_id and init the mark
from the skb->mark, set the oif to zero in the collect metadata
mode.
Fixes: cfc7381b3002 ("ip_tunnel: add collect_md mode to IPIP tunnel")
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 5 +++--
1
From: wenxu
Refactor collect metatdata mode tunnel xmit to the generic xmit function
ip_md_tunnel_xmit. It makes codes more generic and support more feture
such as pmtu_update through ip_md_tunnel_xmit
Signed-off-by: wenxu
---
net/ipv4/ip_gre.c | 112
From: wenxu
This patchset add tunnel_dst_cache and tnl_update_pmtu feature for
ip_md_tunnel_xmit also bugfix. Then Refactor collect metatdata mode
tunnel xmit to ip_md_tunnel_xmit
wenxu (4):
ip_tunnel: Add ip tunnel dst_cache in ip_md_tunnel_xmit
ip_tunnel: Add tnl_update_pmtu in
From: wenxu
Add ip tunnel dst cache in ip_md_tunnel_xmit to make more
efficient for the route lookup.
Signed-off-by: wenxu
---
net/ipv4/ip_tunnel.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
User can set flags with key, csum, seq
ip r a 10.
Hi all,
Are there any other idear for this patch? Maye should modify IFNAMSIZ to
MODULE_NAME_LEN
BR
wenxu
On 2019/1/18 下午10:35, Pablo Neira Ayuso wrote:
> On Fri, Jan 18, 2019 at 03:32:08PM +0100, Florian Westphal wrote:
>> Pablo Neira Ayuso wrote:
>>>> +
From: wenxu
nft "tunnel" expr match both the tun_info of RX and TX. This patch
provide the NFTA_TUNNEL_MODE to individually match the tun_info of
RX or TX.
Signed-off-by: wenxu
---
include/uapi/linux/netfilter/nf_tables.h | 9 +
net/netfilter/nft_tunnel.c
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap Key example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
In the lwtunnel situation, some TUNNEL_FLAGS s
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
Signed-off-by: wenxu
---
include/uapi/
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap Key example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
In the lwtunnel situation, some TUNNEL_FLAGS s
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
Signed-off-by: wenxu
---
include/uapi/
From: wenxu
ip l add dev tun type gretap external
ip r a 10.0.0.1 encap ip dst 192.168.152.171 id 1000 dev gretap
For gretap example when the command set the id but don't set the
TUNNEL_KEY flags. There is no key field in the send packet
User can set flags with key, csum, seq
ip r a 10.
From: wenxu
This patch allows us to match on the tunnel metadata that is available
of the packet. We can use this to validate if the packet comes from/goes
to tunnel and the corresponding tunnel ID in the iptables.
Signed-off-by: wenxu
---
include/uapi/linux/netfilter/xt_tunnel.h | 13
201 - 300 of 405 matches
Mail list logo
