Jon Maloy | 22 Sep 17:23 2014
Picon

Proposal for new subscription service in TIPC

After some discussions with colleagues I have realized it could be useful to add another "topology
subscription" subscription service to TIPC.

I should be possible to subscribe for bearers, not only individual links going up and down. This way, a user
will know if TIPC is capable of external communication at all, e.g. after a NIC card is broken.  Sure, a
program could find out about the state of an interface via other means, but it cannot easily know exactly
which interface(s) TIPC is using at the moment. If we obtain that info from TIPC itself, this will never be
an issue.

Any opinions?

///jon

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
richard.alpe | 19 Sep 11:12 2014
Picon

[PATCH v4 00/15] tipc: new netlink API

From: Richard Alpe <richard.alpe <at> ericsson.com>

v4
Redesigned "socket list command" to address David Millers comments in
net-next v1 of this patchset.

Simply put the problem is that we can have an arbitrary amount of
sockets with an arbitrary amount of associated publications. In the
previous patchset this was solved by nesting as many publications as
possible into a socket. If all didn't fit it sent the same socket again
with the remaining publications. As David Miller pointed out this makes
each message malformed as the receiver cannot by the data itself know if
it has received a complete set or not. This was flagged outside of the
data and the client did the reassemble.

o socket 1
  o publ 1
  o publ 2
o socket 1
  o publ 3
  o publ 4

In this patchset I have divided the socket listing and publication
listing to avoid having nested data of arbitrary size.

TIPC_NL_SOCK_GET now dumps all sockets with any nested connection
information. However it no longer include publication information,
only a HAS_PUBL flag to indicate whether the socket has publications or
not. To compliment this there is a new command TIPC_NL_PUBL_GET which
dumps all publications along with the socket they are associated with.
(Continue reading)

richard.alpe | 11 Sep 10:29 2014
Picon

[PATCH net-next 00/14] tipc: new netlink API

From: Richard Alpe <richard.alpe <at> ericsson.com>

This is a new netlink API for TIPC. It's intended to replace the
existing ASCII API. It utilizes many of the standard netlink
functionalities in the kernel, such as attribute nesting and
input polices.

There are a couple of reasons for this rewrite. The main and most
easily justifiable is that the existing API doesn't scale.  Meaning
that a TIPC cluster with a larger amount of nodes, publications or
ports will rapidly exceed what the exiting API can handle. Resulting
in truncated or corrupt responses. In addition to this, the existing
ASCII API rarely uses "standard" kernel functions and has several
tipc specific functions for sanity checking and string formating.

The new API utilizes standard function for pushing data to socket
buffers and netlink attribute nesting to logically group data.
The new API can handle an arbitrary amount of data for things that
are likely to scale up as the TIPC usage and/or cluster size
increases.

A new user-space tool has been developed to work with this new API.
It is called "tipc" and is part of the "tipc-utils" package that
comes with many Linux distributions.  The new "tipc" tool utilizes
standard functions from libnl to format, send, receive and process
messages. The tool has borrowed design philosophies from git and the
ip tool. Making the syntax resemble that of ip whiles its strong
modularity resembles that of git.

The existing tool for managing TIPC, "tipc-config" remains in the
(Continue reading)

Ying Xue | 11 Sep 05:19 2014

[PATCH net-next v2] rps: support tipc

TIPC protocol introduces an abstract link layer which provides a
reliable message delivery mechanism for connection-based,
connectionless, as well as multicast messages, so this means that
message sequence control and retransmission are conducted on link
layer instead of common transport layer like TCP or SCTP doing.
Therefore, the target CPU for RPS is determined through calculating
a flow hash over 2-tuple (i.e, previous and destination node address).

However, TIPC message header has several different formats, so we
have to consider them separately:

- Multicast message. In multicast message header, previous node
  address is varied, but destination node address is always 0. To
  make RPS deem all multicast messages as one flow to steer them to
  one CPU, 0xffffffff and 0 are assumed as their previous and
  destination node address respectively.

- Connection-oriented message. In this message header, it doesn't
  include valid destination node address, so 0 has to be supposed
  as its destination node address.

- Other unicast message. In this message header, it contains both
  valid previous and destination node address.

Signed-off-by: Ying Xue <ying.xue <at> windriver.com>
---
v2: Revised patch header description.

 MAINTAINERS               |    1 +
 include/linux/tipc_msg.h  |   75 +++++++++++++++++++++++++++++++++++++++++++++
(Continue reading)

Ying Xue | 10 Sep 15:03 2014

[PATCH net-next 0/3] fix two potentail deadlock issues

In the series eliminate two lockdep warnings in patch #1 and patch #3
respectively, by the way the node subscribe infrastructure is removed
in patch 2 as well.

Ying Xue (3):
  tipc: fix a potential deadlock
  tipc: remove node subscribe infrastructure
  tipc: fix lockdep warning when intra-node messages are delivered

 net/tipc/Makefile      |    6 +--
 net/tipc/name_distr.c  |   52 ++++++++++++++++++++++----
 net/tipc/name_distr.h  |    1 +
 net/tipc/name_table.c  |    2 +-
 net/tipc/name_table.h  |    6 +--
 net/tipc/node.c        |   50 +++++++++++++++----------
 net/tipc/node.h        |   12 ++++--
 net/tipc/node_subscr.c |   96 ------------------------------------------------
 net/tipc/node_subscr.h |   63 -------------------------------
 net/tipc/socket.c      |    6 +--
 10 files changed, 94 insertions(+), 200 deletions(-)
 delete mode 100644 net/tipc/node_subscr.c
 delete mode 100644 net/tipc/node_subscr.h

--

-- 
1.7.9.5

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
(Continue reading)

Jon Maloy | 9 Sep 16:07 2014
Picon

Re: [PATCH v2] tipc: allow one link per bearer to neighboring nodes

Yes, you can. Or you can subscribe for the netdev mail list and filer on "tipc".

///jon

> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> Sent: September-09-14 6:49 AM
> To: Jon Maloy; tipc-discussion <at> lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH v2] tipc: allow one link per bearer to
> neighboring nodes
> 
> Hi,
> yes no problem. I guess I can see it on patchwork when the patch serie is
> committed?
> 
> http://patchwork.ozlabs.org/project/netdev/list/
> 
> Regards
> Holger
> 
> 
> On 09/08/2014 02:56 PM, Jon Maloy wrote:
> > Holger,
> > BTW, can you hold this patch a couple of days?
> > One of our team members, Richard Alpe, is just about to  post a big
> > and very intrusive series, and I think he would be happy if he doesn't
> > have to rebase it once more.
> >
> > Just wait until you see that the series has been applied by David M,
> > rebase your patch and send it in. It shouldn't take more than a couple of
(Continue reading)

richard.alpe | 8 Sep 16:42 2014
Picon

[PATCH v3 00/14] tipc: new netlink api

From: Richard Alpe <richard.alpe <at> ericsson.com>

This is a new netlink API for TIPC. It's intended to replace the
existing ASCII API. It utilizes many of the standard netlink
functionalities in the kernel, such as attribute nesting and
input polices.

There is a couple of reasons for this rewrite. The main and most
easily justifiable is that the existing API doesn't scale.
Meaning that a tipc cluster with a larger amount of nodes,
publications or ports will rapidly exceed what the exiting API can
handle. Resulting in truncated responses or even message corruption.
In addition to this, the old ASCII API rarely uses "standard" kernel
functions and has several tipc specific functions for sanity checking
and string formating.

The new API utilizes standard function for pushing data to socket
buffers and netlink attribute nesting to logically group data.
The new API can handle an arbitrary amount of data for things that
are likely to scale up as the tipc usage and/or cluster size
increases.

A new user-space tool has been developed to work with this new API.
It is called "tipc" and is intended to be part of "tipc-utils". It
utilizes standard functions from libnl to format, send, receive
and process messages. The tool has borrowed design philosophies from
git and the ip tool. Making the syntax resemble that of ip whiles
it's strong modularity resembles that of git.

The new "tipc tool" is currently available at:
(Continue reading)

Jon Maloy | 8 Sep 14:29 2014
Picon

Re: [PATCH v2] tipc: allow one link per bearer to neighboring nodes

Hi,
You need to be member of tipc-discussion to have a mail distributed to that list.
But that doesn't stop you from sending the patch to  nedev so that David Miller
can apply it.
Just send the patch to davem <at> davemloft.net, and cc netdev <at> vger.kernel.org,
Erik, Ying and me.

Regards
///jon

PS: You can put "Reviewed-by" instead of "Acked-by" from me in the patch.

> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> Sent: September-08-14 2:38 AM
> To: Jon Maloy; tipc-discussion <at> lists.sourceforge.net
> Subject: Re: [tipc-discussion] [PATCH v2] tipc: allow one link per bearer to
> neighboring nodes
> 
> Ah, ok you need to be member. Then please pick up this patch for your next
> submissions and send it for me if it's ok.
> 
> Regards
> Holger
> 
> 
> On 09/05/2014 04:04 PM, Jon Maloy wrote:
> > In case you are not yourself on tipc-discussion (and I don't think you
> > are), your mails to that list will be dropped. Please cc erik.hugne <at> 
> > ericsson.com and ying.xue <at> windriver.com too.
(Continue reading)

richard.alpe | 8 Sep 11:05 2014
Picon

[PATCH 00/14] tipc: new netlink api

From: Richard Alpe <richard.alpe <at> ericsson.com>

v2

This is a new netlink API for TIPC. It's intended to replace the
existing ASCII API. It utilizes many of the standard netlink
functionalities in the kernel, such as attribute nesting and
input polices.

There is a couple of reasons for this rewrite. The main and most
easily justifiable is that the existing API doesn't scale.
Meaning that a tipc cluster with a larger amount of nodes,
publications or ports will rapidly exceed what the exiting API can
handle. Resulting in truncated responses or even message corruption.
In addition to this, the old ASCII API rarely uses "standard" kernel
functions and has several tipc specific functions for sanity checking
and string formating.

The new API utilizes standard function for pushing data to socket
buffers and netlink attribute nesting to logically group data.
The new API can handle an arbitrary amount of data for things that
are likely to scale up as the tipc usage and/or cluster size
increases.

A new user-space tool has been developed to work with this new API.
It is called "tipc" and is intended to be part of "tipc-utils". It
utilizes standard functions from libnl to format, send, receive
and process messages. The tool has borrowed design philosophies from
git and the ip tool. Making the syntax resemble that of ip whiles
it's strong modularity resembles that of git.
(Continue reading)

Jon Maloy | 5 Sep 15:31 2014
Picon

Re: [PATCH v2] tipc: allow one link per bearer to neighboring nodes


> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> Sent: September-05-14 9:28 AM
> To: Jon Maloy; tipc-discussion <at> lists.sourceforge.net
> Subject: Re: [PATCH v2] tipc: allow one link per bearer to neighboring nodes
> 
> On 09/05/2014 03:22 PM, Jon Maloy wrote:
> >
> >
> >> -----Original Message-----
> >> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> >> Sent: September-05-14 3:12 AM
> >> To: tipc-discussion <at> lists.sourceforge.net
> >> Cc: Holger Brunck; Jon Maloy
> >> Subject: [PATCH v2] tipc: allow one link per bearer to neighboring
> >> nodes
> >>
> >> There is no reason to limit the amount of possible links to a
> >> neighboring node to 2. If we have more then two bearers we can also
> establish more links.
> >>
> >> Signed-off-by: Holger Brunck <holger.brunck <at> keymile.com>
> >> cc: Jon Maloy <jon.maloy <at> ericsson.com>
> > [Jon]
> > Acked-by: Jon Maloy <jon.maloy <at> ericsson.cm>
> >
> > Now it is ok. Are you posting it to netdev yourself (prefix it with
> > "net-next"), or do you want me to do it?
> >
(Continue reading)

Jon Maloy | 5 Sep 15:22 2014
Picon

Re: [PATCH v2] tipc: allow one link per bearer to neighboring nodes


> -----Original Message-----
> From: Holger Brunck [mailto:holger.brunck <at> keymile.com]
> Sent: September-05-14 3:12 AM
> To: tipc-discussion <at> lists.sourceforge.net
> Cc: Holger Brunck; Jon Maloy
> Subject: [PATCH v2] tipc: allow one link per bearer to neighboring nodes
> 
> There is no reason to limit the amount of possible links to a neighboring node
> to 2. If we have more then two bearers we can also establish more links.
> 
> Signed-off-by: Holger Brunck <holger.brunck <at> keymile.com>
> cc: Jon Maloy <jon.maloy <at> ericsson.com>
[Jon] 
Acked-by: Jon Maloy <jon.maloy <at> ericsson.cm>

Now it is ok. Are you posting it to netdev yourself (prefix it with "net-next"),
or do you want me to do it?

///jon

> ---
> 
> Changes in v2:
>  - adapt also error messages to make it consistent with the code change
> 
>  net/tipc/link.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/tipc/link.c b/net/tipc/link.c index fb1485d..8d08c30 100644
(Continue reading)


Gmane