other tunnel technology.
No sure why tcp level mtu probing got disabled by default, any
historic known issues or pitfalls?
[1]: http://www.spinics.net/lists/netdev/msg306502.html
[2]: http://www.ietf.org/rfc/rfc4821.txt
Signed-off-by: Fan Du
---
net/ipv4/tcp_output.c |6 --
1 fil
Introduce ovs_tunnel_route_lookup to consolidate route lookup
shared by vxlan, gre, and geneve ports.
Signed-off-by: Fan Du
---
Change log:
v3:
- Use ovs_tunnel_route_lookup for ovs_tunnel_get_egress_info
- Constantify tun_key structure for gre, vxlan, geneve ports
to surpress warnings
Introduce ovs_tunnel_route_lookup to consolidate route lookup
shared by vxlan, gre, and geneve ports.
Signed-off-by: Fan Du
---
Chnage log:
v2:
- Use inline instead of function call
- Rename vport_route_lookup to ovs_tunnel_route_lookup
---
net/openvswitch/vport-geneve.c | 11
Introduce vport_route_lookup to consolidate route lookup
shared by vxlan, gre, and geneve ports.
Signed-off-by: Fan Du
---
net/openvswitch/vport-geneve.c | 11 +--
net/openvswitch/vport-gre.c| 10 +-
net/openvswitch/vport-vxlan.c | 10 +-
net/openvswitch
于 2015年01月09日 03:55, Jesse Gross 写道:
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote:
>于 2015年01月08日 04:52, Jesse Gross 写道:
>>>
>>>My understanding is:
>>> >controller sets the forwarding rules into kernel datapath, any flow not
>>> >matching
&
于 2015年01月09日 03:55, Jesse Gross 写道:
On Thu, Jan 8, 2015 at 1:39 AM, Fan Du wrote:
于 2015年01月08日 04:52, Jesse Gross 写道:
My understanding is:
controller sets the forwarding rules into kernel datapath, any flow not
matching
with the rules are threw to controller by upcall. Once the rule
于 2015年01月08日 04:52, Jesse Gross 写道:
My understanding is:
>controller sets the forwarding rules into kernel datapath, any flow not
>matching
>with the rules are threw to controller by upcall. Once the rule decision is
>made
>by controller, then, this flow packet is pushed down to datapath to be
>
于 2015年01月07日 03:11, Jesse Gross 写道:
One of the reasons for only doing path MTU discovery
>>for L3 is that it operates seamlessly as part of normal operation -
>>there is no need to forge addresses or potentially generate ICMP when
>>on an L2 network. However, this ignores the IP handling that is
On 2015/1/6 1:58, Jesse Gross wrote:
On Mon, Jan 5, 2015 at 1:02 AM, Fan Du wrote:
于 2014年12月03日 10:31, Du, Fan 写道:
-Original Message-
From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
Sent: Wednesday, December 3, 2014 1:42 AM
To: Michael S. Tsirkin
Cc: Du
于 2014年12月03日 10:31, Du, Fan 写道:
-Original Message-
From: Thomas Graf [mailto:t...@infradead.org] On Behalf Of Thomas Graf
Sent: Wednesday, December 3, 2014 1:42 AM
To: Michael S. Tsirkin
Cc: Du, Fan; 'Jason Wang'; net...@vger.kernel.org; da...@davemloft.net;
f...@strlen.de; dev@openvs
Keep ABI consistent after we replacing EBUSY with EEXIST as
return error in datapath.c:ovs_vport_cmd_new. And cry out louder
when failed in any reason.
Signed-off-by: Fan Du
---
lib/dpif-linux.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/dpif-linux.c b/lib
[ovs-dev] [PATCH] Use EEXIST as return error when adding vport
Hi, Jesse
Those two patches attempts to use EEXIST as return error when trying
to add an vport which is actually already in place as the reason to user.
And furthermore, we warn user in any reason other than EEXIST too.
Thanks
Fan
ovs_vport_cmd_new create a new vport with port num specified by user.
when this port num is already occupied, it's more clear to return
-EEXIST as the reason than -EBUSY.
Signed-off-by: Fan Du
---
datapath/datapath.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --
13 matches
Mail list logo
