gmane.network.tipc.general

Re: TIPC 1.7.7 question.

2013-05-17T11:02:17

Yes


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: TIPC 1.7.7 question.

Azeez Mohammad — 2013-05-17T09:56:04

Hi Eric,

I have WR's latest RCPL 16.

OS has this patch in full
944841a62   net: backlog functions rename

And about this patch
84a326871   net: add limit for socket backlog

The OS has the 'len' but does not have the 'limit'.

    226         struct {
    227                 struct sk_buff *head;
    228                 struct sk_buff *tail;
    229                 int len;
    230         } sk_backlog;

And the OS does not have  sk_add_backlog_limited

[root< at >platbuild linux]# grep -i sk_add_backlog_limited include/net/sock.h
[root< at >platbuild linux]#


With the OS in this situation, is it safe for me to add this condition in tipc_socket.c ?
if (sk_add_backlog(sk, buf))
   res = TIPC_ERR_OVERLOAD;
else
   res = TIPC_OK;

Thanks for taking the time to investigate this.
Azeez

The current code:

226         struct {
227                 struct sk_buff *head;
228                 struct sk_buff *tail;
229                 int len;
230         } sk_backlog;


481 /* OOB backlog add */
482 static inline void __sk_ad

[PATCH 2/2] tipc: add ip/udp media type

2013-05-17T09:45:38

From: Erik Hugne <erik.hugne< at >ericsson.com>

The ip/udp bearer can be configured in a point-to-point
mode by specifying a remote ip/hostname:
tipc-config -be=udp:eth0:<remip>[:<remport>]
If not specified, the UDP port used is 6118 (iana assigned).
Or, it can be enabled in multicast mode:
tipc-config -be=udp:eth0
In this mode, links will be established to all tipc nodes
that are member in the multicast group.

Signed-off-by: Erik Hugne <erik.hugne< at >ericsson.com>
---
 net/tipc/Makefile    |    2 +-
 net/tipc/bearer.h    |    3 +
 net/tipc/core.c      |    4 +
 net/tipc/udp_media.c |  477 ++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 485 insertions(+), 1 deletions(-)
 create mode 100644 net/tipc/udp_media.c

diff --git a/net/tipc/Makefile b/net/tipc/Makefile
index 4df8e02..81fb8bc 100644
--- a/net/tipc/Makefile
+++ b/net/tipc/Makefile
< at >< at > -8,6 +8,6 < at >< at > tipc-y+= addr.o bcast.o bearer.o config.o \
    core.o handler.o link.o discover.o msg.o  \
    name_distr.o  subscr.o name_table.o net.o

[PATCH 0/2] Add IP/UDP bearer support

2013-05-17T09:45:36

From: Erik Hugne <erik.hugne< at >ericsson.com>

I've had this laying around for quite some time now and i figured
it's time to do a push.
The functionality is fairly isolated, the changes done in the core parts and
userspace API is to allow for longer link names that contains a ':' character.
IPv6 support is not yet possible, as that would violate the current protocol
spec (bearer level originating address field is too small).

An updated tipcutils required to configure UDP bearers can be found here:
git clone -b udp_bearer git< at >github.com:Hugne/tipc-config-dev.git

Erik Hugne (2):
  tipc: allow longer link names containing ':' character
  tipc: add ip/udp media type

 include/uapi/linux/tipc_config.h |    9 +-
 net/tipc/Makefile                |    2 +-
 net/tipc/bearer.h                |    3 +
 net/tipc/core.c                  |    4 +
 net/tipc/link.c                  |    5 +-
 net/tipc/udp_media.c             |  477 ++++++++++++++++++++++++++++++++++++++
 6 files changed, 494 insertions(+), 6 deletions(-)

[PATCH 1/2] tipc: allow longer link namescontaining ':' character

2013-05-17T09:45:37

From: Erik Hugne <erik.hugne< at >ericsson.com>

When links are activated, the remote bearer name should be part of
the link name immediately after <remote addr>z:.
This fixes a problem when ':' is part of the bearer name causing
corrupted link names. The interface/bearer/link name limits are
increased to be able to hold IPv6/UDP endpoint names.

Signed-off-by: Erik Hugne <erik.hugne< at >ericsson.com>
---
 include/uapi/linux/tipc_config.h |    9 ++++++---
 net/tipc/link.c                  |    5 +++--
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/tipc_config.h b/include/uapi/linux/tipc_config.h
index 0b1e3f2..e54987b 100644
--- a/include/uapi/linux/tipc_config.h
+++ b/include/uapi/linux/tipc_config.h
< at >< at > -159,9 +159,12 < at >< at >
  */
 
 #define TIPC_MAX_MEDIA_NAME16/* format = media */
-#define TIPC_MAX_IF_NAME16/* format = interface */
-#define TIPC_MAX_BEARER_NAME32/* format = media:interface */
-#define TIPC_MAX_LINK_NAME60/* format = Z.C.N:interface-Z.C.N:interface */
+#define

Re: [RFC PATCH net-next 0/5] introduce linkcongestion control algorithm

Jon Maloy — 2013-05-17T08:50:08

Not me. At least not regarding the principles.
See below.


Current TIPC doesn't have an L3 layer, unless you see the port name lookup as such.
The TIPC link layer is what it sounds like, a reliable signaling link layer,
popularly called L2.5. This is not a new concept, there are several such
protocols around, and it is perfectly consistent with the ISO/OSI model.
So, I see nothing wrong with using specifics knowledge about the media,
as long it is done right, and as long as it gives us any advantage to use
this info.
The link *implementation* must of course be media independent, but if we
can parametrize it with values that reflect the properties of the underlying
layer, there is nothing wrong with that. That was the exact purpose with
the media adaptation layer (eth_media,udp_media etc.) and the media
adaptation API when they were created.


As said, it is not L3, and it is built to be *adaptable towards*, not 
dependent of, the specific media and its properties.


That is almost the same thing in TIPC, a

Re: TIPC 1.7.7 question.

Erik Hugne — 2013-05-17T05:47:29

Prior to kernels 2.6.34, sk_add_backlog would always enqueue an skb to the 
socket backlog. This was later changed and it would do a check vs the 
sk backlog limit before allowing the packet to be enqueued.
TIPC_ERR_OVERLOAD should cause the message to be rejected back to sender
(unless dst_droppable is set).
See tipc_port.c:
1357                 err = p_ptr->dispatcher(&p_ptr->publ, buf);
1358                 tipc_port_unlock(p_ptr);
1359                 if (likely(!err))
1360                         return dsz;
1361         } else {
1362                 err = TIPC_ERR_NO_PORT;
1363         }
1364 reject:
1365         dbg("port->rejecting, err = %x..\n",err);
1366         return tipc_reject_msg(buf, err);

I assume that your Windriver kernel is not a clean 2.6.27, but have some 
patches backported.
Do you have these?
944841a62 net: backlog functions rename
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/include/net/sock.h?id=a3a858ff18a72a8d388e31ab0d98f7e944841a62
84a326871net: add

TIPC 1.7.7 question.

Azeez Mohammad — 2013-05-16T19:48:35

Hi

I sent out emails before about a leak in TIPC 1.7.7 using Windriver 2.6.27.57-WR3.0.3bc_standard while doing a performance test.

I was able to narrow it down to this code. Specifically to lines 1382, 1383 in tipc_socket.c file below.

The TIPC_ERR_OVERLOAD condition is not being checked in 1.7.7 while it was being checked in 1.7.6
Was it intentional?

When I added the code for checking the TIPC_ERR_OVERLOAD condition in tipc_socket.c, the slab is not growing. I added statistics and there were a lot of messages that met the overload condition.

Please let me know if this is a bug or if it is per design.

Thanks
Azeez



tipc_socket.c from TIPC 1.7.7

   1360 static u32 dispatch(struct tipc_port *tport, struct sk_buff *buf)
   1361 {
   1362         struct sock *sk = (struct sock *)tport->usr_handle;
   1363         u32 res;
   1364
   1365         /*
   1366  *          * Process message if socket is unlocked; otherwise add to backlog queue
   1367  *                   *
   1368  *

Re: [RFC PATCH net-next 0/5] introduce link congestion control algorithm

Erik Hugne — 2013-05-16T11:29:53

Ok, you have convinced me :)

What do you think about advertising a lower window value from the
receiver side if there are frequent OOO packets/sequence gaps?

//E

On Thu, May 16, 2013 at 06:49:55PM +0800, Ying Xue wrote:

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: [RFC PATCH net-next 0/5] introduce linkcongestion control algorithm

Ying Xue — 2013-05-16T10:49:55

If we assume TIPC link layer is deemed as L3, and Ethernet as L2,
especially in virtualization network environment, L2 is complex and big,
such as VXLAN, L3 should not depend on some specific L2 device property
like RX ringbuffer size.

If we design one flow control algorithm for link, the link sender window
should correspond to its peer link receiver window instead of its peer
L2 device receiver window.

On TIPC link sender side, there has placed one link send limited window,
but please notice we never limit link receiver queue size, that is, we
can almost treat link receiver window as unlimited size. Furthermore, as
we don't remain window field in TIPC payload message header like window
field in TCP header, TIPC sender cannot know how many receive space in
receiver is available in time, and it don't care about its peer receive
space. Instead, sender only cares about how many number of its sent
messages have been acknowledged by receiver to decide how fast speed it
sends message to the receiver.

As I ever

Re: [RFC PATCH net-next 0/5] introduce link congestion control algorithm

Erik Hugne — 2013-05-15T11:55:07

I'd like to propose some changes to this.

This is from TCP RFC2581, but can be applied for TIPC aswell:
"The congestion window (cwnd) is a sender-side limit on the amount of 
data the sender can transmit into the network before receiving an 
acknowledgment (ACK), while the receiver's advertised window (rwnd) 
is a receiver-side limit on the amount of outstanding data."

So a node must never increase the link window past the value advertised
by the peer.

Changes to patch #3:
We should do our best to advertise a realistic max receive window.
Testing have shown that RX ringbuffer overflows are a very real scenario,
especially for heavy stream connections. So deriving it from these buffers 
for ethernet bearers should be done if at all possible.
But what to do if the underlying device do not support this? (like macvlan).
I think we should advertise the max value (8191) and let the congestion
algorithm sort it out.
This would mean that we end up with a window climb up to 8191, and possibly
(quite likely) a drop

Re: [RFC PATCH] tipc: link RTT measurements

Ying Xue — 2013-05-15T10:26:55

Thanks, I will try to propose some idea based on your patch.


Please remove one redundant white space between "="  and "(" characters.
Add two white space around "*", otherwise, patchcheck.pl will report
format warnings for the patch.


Add two white space around "/".


Please add white space around ">>".


I think the tipc_link_send_proto_msg() prototype is already bad, it
seems adding another parameter makes it worse. I suggest we should
consildate parameters into one strcuture.

Beside above minors errors, the patch is fine to me.

Regards,
Ying



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

[RFC PATCH] tipc: link RTT measurements

2013-05-15T07:20:53

From: Erik Hugne <erik.hugne< at >ericsson.com>

RTT is measured on the link-probe/reply messages that
are now sent out every link_timeout, regardless if the
link is sending data or not.
The SRTT estimation is done using the same formula as TCP.

Signed-off-by: Erik Hugne <erik.hugne< at >ericsson.com>
---
This patch will do the RTT measurement and SRTT/RTTVAR estimations
needed to calculate the RTO. I left the actual RTO calculation out of this
as i'm not sure how it should be done..
I hope we will come up with a way to use this together with the slow-start
patch that Ying posted earlier. I have not experimented with that.

There's a lot of patch noise as i had to change the prototype of
tipc_link_send_proto_msg, sorry for that.

It should apply cleanly on top of my earlier RFC patch series:
tipc: increase the max allowed link windowsize
tipc: select default bearer window from interface txq len
tipc: pass desired link window in ndisc request/response exchange


 net/tipc/bcast.c |    2 +-
 net/tipc/link.c  |   85 +++

Re: Getting link events from topology server?

Erik Hugne — 2013-05-14T08:44:31

The setup that i mentioned used ARP based monitoring for the bonds, with a 
(cross-connected) redundant switch setup that could cause a split-brain 
scenario after a bonding failover.
I'm sorry I dont remember the exact details around this. :/

I dont know much about it either, as i said i never tried it.


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Getting link events from topology server?

Ying Xue — 2013-05-14T07:58:41

Why not enlarge link tolerance time to avoid this issue?


I have little knowledge about LAG, so please give some explanation to
indicate why it works fine in LAG.


Agreed.

Regards,
Ying



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Getting link events from topology server?

Erik Hugne — 2013-05-14T07:40:05

Great!

Imho, bonding is broken by design, and using TIPC on bonded interfaces will 
cause problems.
One issue is that TIPC detects loss of logical link before bonding reacts
and brings up the new slave, considerable amount of time can pass when we
have no connectivity at all.
(We had one problem a while back with this setup leading to flipping links => 
OpenSAF heartbeats are lost => entire cluster reboots).
Maybe it works acceptable in 802.3ad (LAG) mode, but i never tried that.

We're using macvlans for TIPC now, bonding only for IP based services.

 eth0         eth1
  +--+         +--+
  |  |         |  |
  | mvl0       | mvl1
  |            |
  +---bond0----+


For VM<->VM on the same physical blade, dual links is probably unnecessary.
But if you have network devices mapped from the HW up to the VM's (Using for 
example Intel VT-d), link-redundancy are important.

//E

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform de

Re: RTT link statistics?

Jon Maloy — 2013-05-14T03:36:13



Word 8 in the LINK_PROTOCOL header was originally reserved for this. 
It has now been set as "obsoleted", but it is still unused.
So I guess this should be an easy task.

///jon


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: RTT link statistics?

Ying Xue — 2013-05-14T03:22:34

Yes, we don't retransmit probe message normally, but probe or its
response message may be delayed/disordered by switch/router in a complex
network environment, such as UDP bearer, or virtualization network etc.
So the latter case would easily lead to wrapped sequence number of link
protocol message.


I guess we have to add timestamp in the header of link protocol message
to resolve the issue.

Regards,
Ying



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Getting link events from topology server?

Ying Xue — 2013-05-14T02:21:26

I think this is a very useful feature.

Regards,
Ying



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: Getting link events from topology server?

Jon Maloy — 2013-05-13T19:45:04

Allan already did this. In 1.7 I think. You should look at that.
Anyway, this really is only a problem if there are dual links.
Otherwise the existing node subscription gives the information needed.
I have the feeling that people nowadays mostly use single links
across bonded interfaces, or on virtual interfaces between VMs, 
in which case use of dual links makes no sense.
But sure, it should be very easy to implement, so I have no objections
if you see a use for it.

///jon



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

Re: RTT link statistics?

Jon Maloy — 2013-05-13T19:39:03

The trick is knowing that the STATE we receive really is a response from the
probe we sent. It may be that the peer just went into working_unknown state
(the the probe bit is set, so not really a problem, or it may be from an
earlier probe sent. Maybe this reaaly is no problem, but we shouldn't ignore it
until we have the full analysis here.



------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d