gmane.network.tipc.general

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

Ying Xue — 2013-05-23T01:45:28

Maybe you misunderstood my idea :)

I just listed the truth that TCP/SCTP congestion flow sets snd_ssthresh
to a very high value. But for TIPC, I still prefer to use rx_pending as
initial snd_ssthresh value.

But I think it's worth investigating/verifying the two both cases in
real environment. So I will test them. Later I will give their test results.


Please wait, I will verify the two different cases. If you have other
good idea, please tell me.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

RDM and multicast flow control

Jon Maloy — 2013-05-22T16:53:20

Erik and I have been discussing how we can find a satisfactory solution to the RDM and
multicast message overload problem.

I now suggest a combination of two related mechanisms, partially based on Erik's original
suggestion to distribute "overload flags" to all distributed publication items when
overload happens.

A:
---
1) When a receiving socket is approaching overflow, e.g. at LOW_IMPORTANCE-level*0.75, it
scans through the receive queue and identifies the senders which are using LOW_IMPORTANCE.
2) Those senders, or if there are too many, those who contribute most of the load (say,
representing 50% of the load combined) will be sent a message of a new type, called
OVERLOAD_WARNING.
3) When a sender socket receives OVERLOAD_WARNING, it has to mark itself as OVERLOADED
and return -EAGAIN on all sendmsg() calls for the given port name until it receives
an OVERLOAD_FINISHED message from the same socket.
4) The receiving socket issues an OVERLOAD_FINISHED to all the warned senders when the
receive queue length goes below e.g. LOW_IMPORTANCE-level/2.

This procedure is repeated for each importance level.

B:
----
5) If the receiving socket queue still surpasses LOW_IMPORTANCE-level, it issues a new broadcast
NAME_DISTR message called NAME_OVERLOADED or similar. This carries information about
which importance level is affected, and the information is stored in each publish element
in the name table pertaining to the receiver in question.
6) A sender who wants to send a LOW_IMPORTANCE message to the socket in question will now
encounter a flag indicating that "LOW_IMPORTANCE is overloaded" during name lookup,
and will return -EAGAIN to the user if no other, unloaded receiver is found.
Higher importance messages still go through, as they should.
7) When the overload situation has abated, the receiver broadcasts a NAME_DISTR message
to all its peer nodes with information about the new load situation, i.e., OVERLOAD_FINISHED
in this case. (In other cases, it would be "XXX_IMPORTANCE is overloaded" since we are only
taking one step at a time down the overload escalation ladder).

This procedure is repeated for each importance level.

9) Furthermore, we remove the current calculation of rejection limit per importance on the
receiving side.
All messages are now added to the receive queue without qualification, up to the absolute
upper limit, CRITICAL_IMPORTANCE-level (40 MB right now).
This can be done since we can trust that all well-behaved senders (i.e. where the TIPC
implementation is not broken) respect the overload-limit flags found in their local
publication items.

This approach has several major advantages:

1) Receiver overload will initially only affect the senders that should be affected. The
feedback only goes to those senders that have the affected importance level, and will
sooner or later hit the real sources of the overload, irrespective of importance.
2) It escalates if the overload is worsening despite the initial, directed measures, so that
it will eventually affect all senders to the port name in questions. But still only for the
importance level in question.
3) No RDM message will ever be rejected unless a number of senders start to wreak out
CRITICAL_IMPORTANCE messages in an orchestrated attack, where the sender shifts from
socket to socket. We must either assume a malevolent sender or a completely brain-dead
application designer for this to happen. Anyway, not even such an attack would break TIPC
or violate any system resource usage rules. It would only affect the application in question.
4) It works equally well with SOCK_RDM and multicast messaging.

///jon

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Jon Maloy — 2013-05-22T13:26:09

[...]
.

Ok. I have no doubt this will work. But won´t we need fewer loops, and 
have fewer initial congestion situations, if we start with a value which we know 
is the real upper limit anyway?
If you are certain that it makes no difference if we user 8191 or rx_pending,
we get the same frequency of congestion situations and same performance anyway, 
then I can buy that. You measured both cases, I assume?

My reaction was more to your claim that it is wrong, in principle, to use 
rx_pending as start value. It isn't, as long as we don't build it into the
generic part of the link layer (link.c).

If it really is useful, or if we can do just as well without using it, 
that is a different question which you seem to have answered.

Regards
///jon



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T07:12:08

Anyway, my meanings is that I hope that we should handle upd bearer
errors like recv_notification() of Ethernet bearer.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T07:06:11

But I think if we detect some fatal error is unrecoverable, we not only
print warning message to user,but also we should block the bearer, and
this might be better.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Erik Hugne — 2013-05-22T06:58:42

I think we only need to override this if we want to handle the network
errors. But there is not much more we can do other than do a helpful 
pr_info/warn/err.

//E

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T06:35:08


Additionally I guess we have to override sk_error_report callback
handler to monitor/handle some unrecoverable errors from underlaying udp
bearer like:

http://lxr.free-electrons.com/source/net/rxrpc/ar-error.c#L131

Regards,
Ying


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T06:18:13

Sorry, maybe I cannot clearly express my meanings.

In fact, I suggest we should add a new TIPC_MEDIA_UDP in TIPC Kconfig
file so that we can enable or disable the ddp_bearer new feature by our
requirement. For example, InfiniBand media type, it adds a new
TIPC_MEDIA_IB option.

If you think it's unnecessary, it's ok for me.


Fine. :)

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Erik Hugne — 2013-05-22T06:05:02

Not sure i agree with this, we dont have any extra dependencies 
(TIPC already requires CONFIG_INET). And the memory footprint 
for having it enabled is increased by a very small amount.
Jon. do you have any opinion on this?

Ying:
I've fixed it according to your other comments regarding the potential memleak 
in send_msg and useless parameter


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T02:50:30

In fact, we should add transmit work instance into udp_bearer instead of
udp_skb_parms so that the work is not per packet, instead per socket. If
so, we just initialize the work once when create transmission socket.


You are right, I misunderstood your idea. But for me, when sending each
packet, we need to allocate a new work instance, which is a little
expensive.

In contrast, as I mentioned before, the transmission work is designed to
per-socket. And we add one outbound queue list in udp_bearer structure.
When send_msg() sends skb buffer, the skb is only inserted into the
outbound queue, subsequently call queue_work() to schedule the
transmission work.

When tipc_udp_send() is scheduled, it should iterate the outbound queue
to send all skb buffers until the queue is empty or something else.

This design seems more elegant.

In fact, once we can see how to implement tipc server in
net/tipc/server.c, you might understand what I say.


It seems better than before.


Yes, list is better than array, and I will change the array when change
lock policy.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-22T02:04:04

We should add one new config option in Kconfig, for example,
TIPC_MEDIA_UDP, having us not to compile the udp_bearer bearer.

On 05/17/2013 05:45 PM, erik.hugne< at >ericsson.com wrote:

It's unnecessary for us to define the remote variable because we can
directly use dest to memcpy to parms->dst later.


We cannot consolidate two condition statements into one together.
Instead, we should do split them to avoid memory leak as belows:

if (!clone)
return -ENOMEM;
parms = kmalloc(sizeof(struct udp_skb_parms), GFP_ATOMIC);
if (!parms) {
kfree_skb(clone);
return -ENOMEM;
}



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Erik Hugne — 2013-05-21T13:35:57

Thanks Ying!
Responses/questions for all comments inlined below.

On Tue, May 21, 2013 at 06:54:42PM +0800, Ying Xue wrote:

Fixed.


This is needed because the deferred send work might try to push data
out on the socket while the bearer is being disabled.


We need to initialize it here because the work_struct is dynamically allocated 
(udp_skb_parms) per-packet in the send_msg.


queue_work only returns false if the work had already been put on a WQ.
We allocate a work_struct for each packet to be sent, and enqueue it only once.
Even if we get our wires crossed or some weird scheduling bug causes the work
to be enqueued twice, i dont think memory leaks can happen here.


I think this was done in the early versions, but changed to use
(Concurrency Managed) workqueues instead.
Or maybe i'm misunderstanding you?


Fixed.


Yes, it should be safe to remove this check.
But the enabled atomic_t is still neded in the udp bearer struct
to protect the TX path.


Fixed


Fixed.


Fixed.


Fixed.


Fixed.
If we run any problems when setting up the bearer (creating socket, binding
and setting options), i changed it to log an error and disable (remove) the bearer
instead.


Absolutely fixed... :|


Fixed.


Since UDP bearers can be set up in point-to-point mode, we can potentially have
a lot of these. I didn't want to put them in an array restricted to MAX_BEARERS.

Fixed the memory leak where they're not removed from the list upon disabling.


Fixed.
I was happily unaware that you had to protect the sock struct when changing
the callbacks..

I hope to have it tested OK end of the week for a new round.

//E

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-21T10:54:42

It seems unnecessary to define dup_started as atomic variable.


I think the condtion seem unnecessary for us.


Why do we need to initialize the work here? I think we should do the
initialization in enable_bearer().


No, here we should identify queue_work() return value, if failure, we
should release parms as well as the skb, otherwise, memory leak happens.

There has another issues, and skb might be dropped. In fact we should
first insert the skb into one queue buffer list, and schedule send_wq.
In tipc_udp_send(), we should iterate the buffer list to send all skb
buffers in one time or more times.


As we overide sk_data_ready with tipc_udp_recv, so we should with
sk_callback_lock read lock to protect below area.


above statement is unnecessary for us as long as we hold read lock of
sk_callback_lock.


It seems we should remove the white space between ")" and "&".


No, when override socket callback functions, we must hold
sk_callback_lock write lock.


Please notice comments style, we should add comments like below:

 /* ...
  * ..
  */


Please add white space between "*" character and O, as well as the end
of * character.


It's not a good idea to call BUG_ON() marco if no system memeory. In
contrast, it's better to return ENOMEM.

When we call BUG_ON(), it will panic the whole system. But sometime, if
we cannot allocate memory sucessfully in the first time, maybe it will
suceed in next try.


Before we return -ENODEV, we should call kfree(ub_ptr), right?


Please follow/align other bearer setup function name like setup_bearer()
instead of enable_bearer_wh().


Why do we need the bearer_list? I just see adding one udp bearer into
the global list, but don't see where one bearer is removed from the list.


Please notice that we cannot so simply close sockets.
Instead, we should first hold write sk_callback_lock lock, and set
sk_user_data to NULL. And we should identify whether sk_user_data is
NULL or not firstly in tipc_udp_recv().

If we do this, I think we can avoid some conditin race, and can safely
close sockets.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-21T02:30:57

If I understood your question correctly, I guess you meaning is that
receiver side should advertise a lower rwnd to sender if it detects
packet gap or packet disordered.

I think it seems unnecessary for receiver to advertise its rwnd to
sender, because:

1. Currently sender is able to extract packet sequence gap from STATE
message sent by receiver. So, sender can use the gap as one of
conditions of identifying whether congestion occurs or not.

2. Even if receiver is allowed to advertise a lower rwnd to sender when
its received packet is out of order, we cannot find one available field
to convey the "rwnd" info in message header of payload message or link
protocol message.

However, your question reminds me that I recall another idea about how
receiver limits the speed send sends message with your mentioned info:

We can adjust ack policy on receiver side to lower send speed, for
example, delay to send ACK message to receiver.

Regards,
Ying




------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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

Ying Xue — 2013-05-21T02:17:01

Sorry, I cannot understand why it's same as its peer Ethernet receive
ring buffer size. I try to get an exact answer by digging more related
code from Ethernet driver and net dev code(ie. dev.c) to TIPC link
layer. But, at least, for me the link receive window seems different
with its peer Ethernet receive queue size.

Please see below call paths when TIPC link receives packets from driver:

XX_Ethernet_rx_interrupt()
   netif_rx()  <== if the driver doesn't support NAPI, otherwise
   netif_receive_skb() <== if driver supports NAPI
     enqueue_to_backlog()
       napi_schedule()
         raise_softirq_irqoff(NET_RX_SOFTIRQ)
            net_rx_action()
              process_backlog()(ie, n->poll <==> backlog.poll)
                __netif_receive_skb()
                   __netif_receive_skb_core()
                     deliver_skb()
                         tipc_recv_msg()

The rx_pending in struct ethtool_ringparam only affects
XX_Ethernet_rx_interrupt().

For Ethernet driver, there has two type driver: single rx queue or
multi-rx queue.

For single rx queue, if the number of received frames exceeds the
rx_pending, the single rx fifo queue is overflowed, and frame loss happens.

For multi-rx queue, if the number of received frames on one of rx queues
is over the rx_pending, the rx queue is overflowed.

Particularly for some modern Ethernet driver, it may support the total
number of rx queue up to 16 or even 32.

As most of Ethernet hardware follows round-robin policy when dispatching
interrupt signal which frame arrives at Ethernet hardware to each CPU,
we should pass the value of (rx_pending*total queue number of Ethernet)
to TIPC peer link as its rx ringbuffer size instead of one rx_pending.

On other hand, even if we know how many rx queue one Ethernet driver
has, the number of CPUs for one host also significantly affects whether
each rx queue of Ethernet overruns or not.

For example, for one Ethernet with 16 rx queues, if one host has two
CPUs, but another has 16, 32 or even 64 CPUs, the rating of rx queue
overflowing is much different between them.

Another function(enqueue_to_backlog()) also affects the loss of packets.

That's why I propose to enlarge the netdev_max_backlog with sysctl.

So, different netdev_max_backlog value might lead to different rating of
packet loss.

Lastly, in tipc_recv_msg(), link receive queue size is never limited
unless link reset happens due to retransmission failure or something else.

Additionally, system workload also has negative influence on packet loss.

So with different Ethernet, different CPU numbers, different CPU speed,
different system configuration like different netdev_max_backlog, and
different workload, the rating of packet loss might become different.

Therefore, it's very hard for us to teat the rx_pending got from
Ethernet driver as link receive window.

 The problem

No, that's not truth. For example, in my test I used two Cavium boards.
They has 64 cores separately, and the rx_pending passed from its peer
Ethernet driver is 1000. Even if snd_wnd is finally increased up to 8191
by the congestion control algorithm, no any congestion happens.

So we cannot believe in the rx_pending too much.

In fact, I never oppose the value of using rx_pending of Ethernet.
Instead, in the implementation of link flow control algorithm, I used
the minimize value between tx ringbuffer szie of local host and rx
ringbuffer of peer remote as initial value of ssthresh(the slow start
threshold), which is used to determine whether the slow start or
congestion avoidance algorithm is used to control data transmission.

As I described before, the initial value of ssthresh can be set to very
high like RFC2852 specification. For example, we can set it to 8191
initially.

Why is the latter also feasible for us?

Please notice the initial ssthresh will be changed with below equation
once congestion occurs:

snd_ssthresh = max (snd_cwnd / 2, TIPC_MIN_LINK_WIN)

Even if we don't use other Ethernet's parameters as the initial
ssthresh, in contrast, set it to 8191, the flow control algorithm can
select one optimal value for ssthresh finally after several loops.

Regards,
Ying



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

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_add_backlog(struct sock *sk, struct sk_buff *skb)
483 {
484         if (!sk->sk_backlog.tail) {
485                 sk->sk_backlog.head = sk->sk_backlog.tail = skb;
486         } else {
487                 sk->sk_backlog.tail->next = skb;
488                 sk->sk_backlog.tail = skb;
489         }
490         skb->next = NULL;
491 }


503 /* The per-socket spinlock must be held here. */
504 static inline __must_check int sk_add_backlog(struct sock *sk, struct sk_buff *skb)
505 {
506         if (sk_rcvqueues_full(sk, skb))
507                 return -ENOBUFS;
508         __sk_add_backlog(sk, skb);
509         sk->sk_backlog.len += skb->truesize;
510         return 0;
511 }



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
84a326871   net: add limit for socket backlog
http://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/include/net/sock.h?id=8eae939f1400326b06d0c9afe53d2a484a326871

That would explain why it's leaking skb's during overload.

//E

On Thu, May 16, 2013 at 02:48:35PM -0500, Azeez Mohammad wrote:
 o monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infinite e-mail system.




Thanks,
Azeez
224 764 3593| 224 764 3430
Web site:  www.infinite-convergence.com<http://www.infinite-convergence.com> | azeez.mohammad< at >infinite.com
Infinite Convergence Solutions | Enabling Communication


______________________________________________________________________________________________________________________________

This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify so to the sender by e-mail and delete the original message. In such cases, please notify us immediately at sanchar-sadhan< at >infinite.com . Further, you are not to copy, disclose, or distribute this e-mail or its contents to any unauthorized person(s) .Any such actions are considered unlawful. This e-mail may contain viruses. Infinite has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachments. Infinite reserves the right to monitor and review the content of al
 l messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infinite e-mail system. 

***INFINITE******** End of Disclaimer********INFINITE******** 
------------------------------------------------------------------------------
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

[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  \
    netlink.o node.o node_subscr.o port.o ref.o  \
-   socket.o log.o eth_media.o
+   socket.o log.o eth_media.o udp_media.o
 
 tipc-$(CONFIG_TIPC_MEDIA_IB)+= ib_media.o
diff --git a/net/tipc/bearer.h b/net/tipc/bearer.h
index 09c869a..6dc946d 100644
--- a/net/tipc/bearer.h
+++ b/net/tipc/bearer.h
< at >< at > -57,6 +57,7 < at >< at >
  */
 #define TIPC_MEDIA_TYPE_ETH1
 #define TIPC_MEDIA_TYPE_IB2
+#define TIPC_MEDIA_TYPE_UDP3
 
 /**
  * struct tipc_media_addr - destination address used by TIPC bearers
< at >< at > -182,6 +183,8 < at >< at > void tipc_ib_media_stop(void);
 static inline int tipc_ib_media_start(void) { return 0; }
 static inline void tipc_ib_media_stop(void) { return; }
 #endif
+int  tipc_udp_media_start(void);
+void tipc_udp_media_stop(void);
 
 int tipc_media_set_priority(const char *name, u32 new_value);
 int tipc_media_set_window(const char *name, u32 new_value);
diff --git a/net/tipc/core.c b/net/tipc/core.c
index 7ec2c1e..ebe693c 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
< at >< at > -83,6 +83,7 < at >< at > static void tipc_core_stop_net(void)
 tipc_net_stop();
 tipc_eth_media_stop();
 tipc_ib_media_stop();
+tipc_udp_media_stop();
 }
 
 /**
< at >< at > -99,6 +100,9 < at >< at > int tipc_core_start_net(unsigned long addr)
 res = tipc_ib_media_start();
 if (res < 0)
 goto err;
+res = tipc_udp_media_start();
+if (res < 0)
+goto err;
 return res;
 
 err:
diff --git a/net/tipc/udp_media.c b/net/tipc/udp_media.c
new file mode 100644
index 0000000..0d55545
--- /dev/null
+++ b/net/tipc/udp_media.c
< at >< at > -0,0 +1,477 < at >< at >
+/*
+ * net/tipc/udp_media.c: IP bearer support for TIPC
+ *
+ * Copyright (c) 2013, Ericsson AB
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *    contributors may be used to endorse or promote products derived from
+ *    this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include "core.h"
+#include "bearer.h"
+#include <linux/socket.h>
+#include <net/sock.h>
+#include <linux/ip.h>
+#include <linux/udp.h>
+#include <linux/inet.h>
+#include <linux/kernel.h>
+#include <linux/workqueue.h>
+#include <linux/list.h>
+#include <linux/inetdevice.h>
+
+#define IP_ADDR_OFFSET4
+#define UDP_PORT_DEFAULT6118
+#define UDP_MCAST_PREFIX"228.0."
+
+struct udp_skb_parms {
+struct work_struct work;
+struct sockaddr_in dst;
+struct udp_bearer *ub_ptr;
+struct sk_buff *skb;
+};
+
+/**
+ * struct udp_bearer - ip/udp bearer data structure
+ * < at >bearer:associated generic tipc bearer
+ * < at >listen:bearer listener socket
+ * < at >transmit:transmit socket
+ * < at >next:list pointer
+ * < at >work:used to schedule deferred work on a bearer
+ */
+struct udp_bearer {
+atomic_t enabled;
+struct tipc_bearer *bearer;
+struct socket *listen;
+struct socket *transmit;
+struct list_head next;
+struct work_struct work;
+};
+
+static LIST_HEAD(bearer_list);
+static struct workqueue_struct *send_wq;
+static atomic_t udp_started;
+
+static int send_msg(struct sk_buff *skb, struct tipc_bearer *tb_ptr,
+    struct tipc_media_addr *dest);
+static int enable_bearer(struct tipc_bearer *tb_ptr);
+static void disable_bearer(struct tipc_bearer *tb_ptr);
+
+/**
+ * udp_media_addr_set - convert a ip/udp address to a TIPC media address
+ */
+static void udp_media_addr_set(struct tipc_media_addr *addr,
+       struct sockaddr_in *sin)
+{
+memset(addr, 0, sizeof(struct tipc_media_addr));
+addr->media_id = TIPC_MEDIA_TYPE_UDP;
+memcpy(addr->value, sin, sizeof(struct sockaddr_in));
+if (ipv4_is_multicast(sin->sin_addr.s_addr))
+addr->broadcast = 1;
+}
+
+/**
+ * udp_addr2str - convert ip/udp address to string
+ */
+static int udp_addr2str(struct tipc_media_addr *a, char *buf, int size)
+{
+snprintf(buf, size, "%pI4", a->value);
+return 0;
+}
+
+/**
+ * udp_msg2addr - extract an ip/udp address from a TIPC ndisc message
+ */
+static int udp_msg2addr(const struct tipc_bearer *b_ptr,
+struct tipc_media_addr *a, char *msg_area)
+{
+struct sockaddr_in *sin;
+
+sin = (struct sockaddr_in *) (msg_area + IP_ADDR_OFFSET);
+if (msg_area[TIPC_MEDIA_TYPE_OFFSET] != TIPC_MEDIA_TYPE_UDP)
+return -EINVAL;
+udp_media_addr_set(a, sin);
+return 0;
+}
+
+/**
+ * udp_addr2msg - write an ip/udp address to a TIPC ndisc message
+ */
+static int udp_addr2msg(struct tipc_media_addr *a, char *msg_area)
+{
+memset(msg_area, 0, TIPC_MEDIA_ADDR_SIZE);
+msg_area[TIPC_MEDIA_TYPE_OFFSET] = TIPC_MEDIA_TYPE_UDP;
+memcpy(msg_area + IP_ADDR_OFFSET, &a->value,
+       sizeof(struct sockaddr_in));
+return 0;
+}
+
+static struct tipc_media udp_media_info = {
+.send_msg= send_msg,
+.enable_bearer= enable_bearer,
+.disable_bearer= disable_bearer,
+.addr2str= udp_addr2str,
+.addr2msg= udp_addr2msg,
+.msg2addr= udp_msg2addr,
+.priority= TIPC_DEF_LINK_PRI,
+.tolerance= TIPC_DEF_LINK_TOL,
+.window= TIPC_DEF_LINK_WIN,
+.type_id= TIPC_MEDIA_TYPE_UDP,
+.name= "udp"
+};
+
+/**
+ * tipc_udp_send - send a TIPC buffer to the bearer socket
+ */
+static void tipc_udp_send(struct work_struct *work)
+{
+struct msghdr msg;
+struct kvec iov;
+struct sk_buff *skb;
+struct udp_skb_parms *parms;
+int err;
+
+memset(&msg, 0, sizeof(struct msghdr));
+parms = container_of(work, struct udp_skb_parms, work);
+skb = parms->skb;
+iov.iov_base = skb->data;
+iov.iov_len = skb->len;
+msg.msg_iov = (struct iovec *) &iov;
+msg.msg_name = &parms->dst;
+msg.msg_namelen = sizeof(struct sockaddr_in);
+err = kernel_sendmsg(parms->ub_ptr->transmit, &msg,
+     &iov, 1, skb->len);
+if (unlikely(err < 0))
+pr_warn_ratelimited("sendmsg on bearer %s failed with %d\n",
+    parms->ub_ptr->bearer->name, err);
+kfree(parms);
+consume_skb(skb);
+}
+
+/**
+ * send_msg - enqueue a send request
+ *
+ * The send request need to be deferred since we cannot call kernel
+ * socket API functions while holding the link spinlock.
+ */
+static int send_msg(struct sk_buff *skb, struct tipc_bearer *tb_ptr,
+    struct tipc_media_addr *dest)
+{
+struct udp_bearer *ub_ptr;
+struct sk_buff *clone;
+struct tipc_media_addr *remote = dest;
+struct udp_skb_parms *parms;
+
+ub_ptr = tb_ptr->usr_handle;
+if (!atomic_read(&ub_ptr->enabled))
+return -ENODEV;
+clone = skb_clone(skb, GFP_ATOMIC);
+parms = kmalloc(sizeof(struct udp_skb_parms), GFP_ATOMIC);
+if (!parms || !clone)
+return -ENOMEM;
+
+INIT_WORK(&parms->work, tipc_udp_send);
+/*Ndisc code uses temporary stack allocated media_addr
+  so we must copy it before deferring
+ */
+memcpy(&parms->dst, remote, sizeof(struct sockaddr_in));
+parms->ub_ptr = ub_ptr;
+parms->skb = clone;
+
+queue_work(send_wq, &parms->work);
+return 0;
+}
+
+/**
+ * tipc_udp_recv - read data from bearer socket
+ *
+ */
+static void tipc_udp_recv(struct sock *sk, int bytes)
+{
+struct sk_buff *skb;
+struct udp_bearer *ub_ptr;
+int err;
+
+skb = skb_recv_datagram(sk, 0, 1, &err);
+if (err == -EAGAIN)
+return;
+skb_pull(skb, sizeof(struct udphdr));
+skb->next = NULL;
+ub_ptr = sk->sk_user_data;
+WARN_ON(!ub_ptr);
+
+if (atomic_read(&ub_ptr->enabled))
+tipc_recv_msg(skb, ub_ptr->bearer);
+else
+consume_skb(skb);
+}
+
+/**
+ * init_mcast_bearer - set up igmp membership for a bearer
+ *
+ */
+static void init_mcast_bearer(struct sockaddr_in *ifaddr,
+      struct udp_bearer *ub_ptr)
+{
+struct ip_mreq mreq;
+struct tipc_bearer *b_ptr;
+struct sockaddr_in *bcast;
+const int mloop = 0;
+int err;
+
+b_ptr = ub_ptr->bearer;
+bcast = (struct sockaddr_in *) &b_ptr->bcast_addr.value;
+memcpy(&mreq.imr_multiaddr.s_addr, &bcast->sin_addr.s_addr,
+       sizeof(struct in_addr));
+mreq.imr_interface.s_addr = ifaddr->sin_addr.s_addr;
+err = kernel_setsockopt(ub_ptr->transmit, IPPROTO_IP,
+IP_ADD_MEMBERSHIP,
+(char *)&mreq, sizeof(mreq));
+WARN_ON(err);
+err = kernel_setsockopt(ub_ptr->transmit, IPPROTO_IP,
+IP_MULTICAST_LOOP, (char *) &mloop,
+sizeof(mloop));
+WARN_ON(err);
+err = kernel_bind(ub_ptr->transmit, (struct sockaddr *) bcast,
+  sizeof(struct sockaddr_in));
+WARN_ON(err);
+}
+
+/**
+ * enable_bearer_wh - deferred udp bearer initialization
+ * < at >work:work struct holding the udp bearer pointer
+ *
+ * create and initialize the listen and transmit udp sockets
+ */
+static void enable_bearer_wh(struct work_struct *work)
+{
+struct sockaddr_in *listen;
+struct sockaddr_in *bcast;
+struct udp_bearer *ub_ptr;
+struct tipc_bearer *tb_ptr;
+int err;
+
+ub_ptr = container_of(work, struct udp_bearer, work);
+tb_ptr = ub_ptr->bearer;
+listen = (struct sockaddr_in *) &ub_ptr->bearer->addr;
+err = sock_create_kern(AF_INET, SOCK_DGRAM, 0, &ub_ptr->listen);
+BUG_ON(err);
+err = kernel_bind(ub_ptr->listen, (struct sockaddr *)listen,
+  sizeof(struct sockaddr_in));
+WARN_ON(err);
+
+err = sock_create_kern(AF_INET, SOCK_DGRAM, 0, &ub_ptr->transmit);
+BUG_ON(err);
+bcast = (struct sockaddr_in *) &tb_ptr->bcast_addr.value;
+if (ipv4_is_multicast(bcast->sin_addr.s_addr))
+init_mcast_bearer(listen, ub_ptr);
+
+ub_ptr->transmit->sk->sk_data_ready = tipc_udp_recv;
+ub_ptr->listen->sk->sk_data_ready = tipc_udp_recv;
+ub_ptr->transmit->sk->sk_user_data = ub_ptr;
+ub_ptr->listen->sk->sk_user_data = ub_ptr;
+atomic_set(&ub_ptr->enabled, 1);
+}
+
+/**
+ * getopt - deconstruct colon separated parameter string
+ * < at >str:parameter string
+ * < at >opt:output parameter
+ *
+ * opt is set to the first parameter value in str
+ * returns the length of opt, including \0
+ */
+static int getopt(char *str, char **opt)
+{
+char *end;
+
+if (*str == '\0')
+return 0;
+*opt = str;
+end = strchr(str, ':');
+if (end)
+*end = '\0';
+return strlen(*opt) + 1;
+}
+
+/**
+ * get_udpopts - parse udp bearer configuration
+ * < at >arg:bearer configuration string, including media name
+ * < at >local:output struct holding local ip/port
+ * < at >remote:output struct holding remote ip/port
+ */
+static int get_udpopts(char *arg, struct sockaddr_in *local,
+       struct sockaddr_in *remote)
+{
+char *opt = NULL;
+char str[TIPC_MAX_BEARER_NAME];
+int i;
+unsigned long port;
+int len = 0;
+char opt_default[16];
+
+local->sin_family = AF_INET;
+remote->sin_family = AF_INET;
+strncpy(str, arg, TIPC_MAX_BEARER_NAME);
+/*Skip media name*/
+len += getopt(str, &opt);
+/*Get the local address*/
+len += getopt(str + len, &opt);
+if (!in4_pton(opt, -1, (u8 *) &local->sin_addr.s_addr, 0, NULL))
+return -EINVAL;
+
+/*Optionally get the local port, or use default*/
+port = UDP_PORT_DEFAULT;
+i = getopt(str + len, &opt);
+if (i) {
+if (kstrtoul(opt, 10, &port) || (port == 0 || port > 65535))
+return -EINVAL;
+len += i;
+}
+local->sin_port = htons(port);
+
+/*Optionally get the discovery address,
+  or use generated one based on network id
+ */
+sprintf(opt_default, UDP_MCAST_PREFIX"%u.%u",
+(tipc_net_id >> 8), (tipc_net_id & 0xFF));
+opt = opt_default;
+len += getopt(str + len, &opt);
+if (!in4_pton(opt, -1, (u8 *)&remote->sin_addr.s_addr, 0 , NULL))
+return -EINVAL;
+
+/*Optionally get the remote port, or use default*/
+port = UDP_PORT_DEFAULT;
+i = getopt(str + len, &opt);
+if (i) {
+if (kstrtoul(opt, 10, &port) || (port == 0 || port > 65535))
+return -EINVAL;
+}
+remote->sin_port = htons(port);
+
+return 0;
+}
+
+/**
+ * enable_bearer - callback to create a new udp bearer instance
+ * < at >tb_ptr:pointer to generic tipc_bearer
+ *
+ * validate the bearer parameters and perform basic initialization of the
+ * udp_bearer, the kernel socket setup is deferred
+ */
+static int enable_bearer(struct tipc_bearer *tb_ptr)
+{
+struct udp_bearer *ub_ptr;
+struct sockaddr_in listen;
+struct sockaddr_in *bcast;
+struct net_device *dev;
+
+ub_ptr = kmalloc(sizeof(struct udp_bearer), GFP_ATOMIC);
+BUG_ON(!ub_ptr);
+
+bcast = (struct sockaddr_in *) &tb_ptr->bcast_addr.value;
+memset(bcast, 0, sizeof(tb_ptr->bcast_addr.value));
+if (get_udpopts(tb_ptr->name, &listen, bcast) == -EINVAL) {
+kfree(ub_ptr);
+return -EINVAL;
+}
+tb_ptr->bcast_addr.media_id = TIPC_MEDIA_TYPE_UDP;
+tb_ptr->bcast_addr.broadcast = 1;
+dev = ip_dev_find(&init_net, listen.sin_addr.s_addr);
+if (!dev)
+return -ENODEV;
+
+atomic_set(&ub_ptr->enabled, 0);
+tb_ptr->usr_handle = ub_ptr;
+ub_ptr->bearer = tb_ptr;
+tb_ptr->mtu = dev->mtu - sizeof(struct iphdr) - sizeof(struct udphdr);
+tb_ptr->blocked = 0;
+udp_media_addr_set(&tb_ptr->addr, &listen);
+INIT_WORK(&ub_ptr->work, enable_bearer_wh);
+schedule_work(&ub_ptr->work);
+list_add_tail(&ub_ptr->next, &bearer_list);
+return 0;
+}
+
+/**
+ * cleanup_bearer - break the socket/bearer association
+ */
+static void cleanup_bearer(struct work_struct *work)
+{
+struct udp_bearer *ub_ptr;
+
+ub_ptr = container_of(work, struct udp_bearer, work);
+sock_release(ub_ptr->listen);
+sock_release(ub_ptr->transmit);
+kfree(ub_ptr);
+}
+
+/**
+ * disable_bearer - detach bearer from socket
+ */
+static void disable_bearer(struct tipc_bearer *tb_ptr)
+{
+struct udp_bearer *ub_ptr;
+
+ub_ptr = (struct udp_bearer *)tb_ptr->usr_handle;
+INIT_WORK(&ub_ptr->work, cleanup_bearer);
+atomic_set(&ub_ptr->enabled, 0);
+schedule_work(&ub_ptr->work);
+}
+
+/**
+ * tipc_udp_media_start - register ip/udp media type with the TIPC bearer code
+ *
+ */
+int tipc_udp_media_start(void)
+{
+int res;
+
+if (atomic_read(&udp_started))
+return -EINVAL;
+res = tipc_register_media(&udp_media_info);
+if (res)
+return res;
+send_wq = alloc_workqueue("tipc_udp_send", 0, 0);
+if (IS_ERR(send_wq))
+return PTR_ERR(send_wq);
+
+atomic_set(&udp_started, 1);
+return res;
+}
+
+/**
+ * tipc_udp_media_stop - deactivate ip/udp bearer support
+ */
+void tipc_udp_media_stop(void)
+{
+if (atomic_read(&udp_started))
+return;
+destroy_workqueue(send_wq);
+atomic_set(&udp_started, 0);
+}

[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(-)
 create mode 100644 net/tipc/udp_media.c

[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 TIPC_MAX_IF_NAME96/* format = interface/
+    ip[:port:ip:port] */
+#define TIPC_MAX_BEARER_NAME128/* format = media:interface/
+    ip[:port:ip:port] */
+#define TIPC_MAX_LINK_NAME256/* format = Z.C.N:interface-
+    Z.C.N:interface */
 
 /*
  * Link priority limits (min, default, max, media default)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index a80feee..014a7ab 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
< at >< at > -2011,6 +2011,7 < at >< at > static void link_recv_proto_msg(struct tipc_link *l_ptr, struct sk_buff *buf)
 u32 max_pkt_info;
 u32 max_pkt_ack;
 u32 msg_tol;
+char *remote;
 struct tipc_msg *msg = buf_msg(buf);
 
 if (link_blocked(l_ptr))
< at >< at > -2048,8 +2049,8 < at >< at > static void link_recv_proto_msg(struct tipc_link *l_ptr, struct sk_buff *buf)
 /* fall thru' */
 case ACTIVATE_MSG:
 /* Update link settings according other endpoint's values */
-strcpy((strrchr(l_ptr->name, ':') + 1), (char *)msg_data(msg));
-
+remote = strchr(l_ptr->name, '-');
+strcpy((strchr(remote, ':') + 1), (char *)msg_data(msg));
 msg_tol = msg_link_tolerance(msg);
 if (msg_tol > l_ptr->tolerance)
 link_set_supervision_props(l_ptr, msg_tol);

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, at least on Ethernet. The problem
is of course that we may have many links towards a node that all share
this resource. So, the ring buffer only gives an absolute upper limit
for the receive window, which it is never meaningful to go beyond.
After that, we still have to adapt the individual window size per link,
as you suggest.


Again, why not? If it can bring us some advantage.


Hopefully the throughput should be better. We should make it possible
for TIPC to take advantage of this. That is what is is designed for.
If don't have such values available, maybe on some virtualized ethernet
NICS or other types of bearers, 

TIPC should of course work well with any bearer, using its default settings, 
just like TCP. But if we can do better we should. There is no reason to throw
away useful information, if it can give us better performance.


TIPC doesn *need* to know. But if it can work better by using 
the RX buffer size as base for the rx buffer in its calculations,
this can only be good.

///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