3 Patches for TIPC 1.6
Stephens, Allan <allan.stephens <at> windriver.com>
2007-05-15 14:47:14 GMT
Hi Jon:
Attached you will find 3 more patches for submission to the TIPC 1.6
stream. They were generated from the master TIPC repository, which is
currently updated to Linux 2.6.21.
Please review, validate, and pass on to David Miller.
Regards,
Al
From nobody Mon Sep 17 00:00:00 2001
From: Allan Stephens <allan.stephens <at> windriver.com>
Date: Tue, 15 May 2007 10:34:15 -0400
Subject: [PATCH] [TIPC]: Optimize stream send routine to avoid fragmentation
This patch enhances TIPC's stream socket send routine so that
it avoids transmitting data in chunks that require fragmentation
and reassembly, thereby improving performance at both the
sending and receiving ends of the connection.
The "maximum packet size" hint that records MTU info allows
the socket to decide how big a chunk it should send; in the
event that the hint has become stale, fragmentation may still
occur, but the data will be passed correctly and the hint will
be updated in time for the following send. Note: The 66060 byte
pseudo-MTU used for intra-node connections requires the send
routine to perform an additional check to ensure it does not
exceed TIPC"s limit of 66000 bytes of user data per chunk.
Signed-off-by: Allan Stephens <allan.stephens <at> windriver.com>
---
include/net/tipc/tipc_port.h | 2 ++
net/tipc/link.c | 12 ++++++------
net/tipc/port.c | 6 +++---
net/tipc/port.h | 2 --
net/tipc/socket.c | 25 +++++++++++++++++--------
5 files changed, 28 insertions(+), 19 deletions(-)
ab11d4a37b305486fbc380386990cde6b4c225a2
diff --git a/include/net/tipc/tipc_port.h b/include/net/tipc/tipc_port.h
index 333bba6..5e5e67f 100644
--- a/include/net/tipc/tipc_port.h
+++ b/include/net/tipc/tipc_port.h
<at> <at> -55,6 +55,7 <at> <at> #define TIPC_FLOW_CONTROL_WIN 512
* <at> conn_unacked: number of unacknowledged messages received from peer port
* <at> published: non-zero if port has one or more associated names
* <at> congested: non-zero if cannot send because of link or port congestion
+ * <at> max_pkt: maximum packet size "hint" used when building messages sent by port
* <at> ref: unique reference to port in TIPC object registry
* <at> phdr: preformatted message header used when sending messages
*/
<at> <at> -68,6 +69,7 <at> <at> struct tipc_port {
u32 conn_unacked;
int published;
u32 congested;
+ u32 max_pkt;
u32 ref;
struct tipc_msg phdr;
};
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 2124f32..1f731f3 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
<at> <at> -1260,7 +1260,7 <at> <at> again:
* (Must not hold any locks while building message.)
*/
- res = msg_build(hdr, msg_sect, num_sect, sender->max_pkt,
+ res = msg_build(hdr, msg_sect, num_sect, sender->publ.max_pkt,
!sender->user_port, &buf);
read_lock_bh(&tipc_net_lock);
<at> <at> -1271,7 +1271,7 <at> <at> again:
if (likely(l_ptr)) {
if (likely(buf)) {
res = link_send_buf_fast(l_ptr, buf,
- &sender->max_pkt);
+ &sender->publ.max_pkt);
if (unlikely(res < 0))
buf_discard(buf);
exit:
<at> <at> -1299,12 +1299,12 <at> <at> exit:
* then re-try fast path or fragment the message
*/
- sender->max_pkt = link_max_pkt(l_ptr);
+ sender->publ.max_pkt = link_max_pkt(l_ptr);
tipc_node_unlock(node);
read_unlock_bh(&tipc_net_lock);
- if ((msg_hdr_sz(hdr) + res) <= sender->max_pkt)
+ if ((msg_hdr_sz(hdr) + res) <= sender->publ.max_pkt)
goto again;
return link_send_sections_long(sender, msg_sect,
<at> <at> -1357,7 +1357,7 <at> <at> static int link_send_sections_long(struc
again:
fragm_no = 1;
- max_pkt = sender->max_pkt - INT_H_SIZE;
+ max_pkt = sender->publ.max_pkt - INT_H_SIZE;
/* leave room for tunnel header in case of link changeover */
fragm_sz = max_pkt - INT_H_SIZE;
/* leave room for fragmentation header in each fragment */
<at> <at> -1463,7 +1463,7 <at> <at> error:
goto reject;
}
if (link_max_pkt(l_ptr) < max_pkt) {
- sender->max_pkt = link_max_pkt(l_ptr);
+ sender->publ.max_pkt = link_max_pkt(l_ptr);
tipc_node_unlock(node);
for (; buf_chain; buf_chain = buf) {
buf = buf_chain->next;
diff --git a/net/tipc/port.c b/net/tipc/port.c
index bcd5da0..01481af 100644
--- a/net/tipc/port.c
+++ b/net/tipc/port.c
<at> <at> -239,6 +239,8 <at> <at> u32 tipc_createport_raw(void *usr_handle
}
tipc_port_lock(ref);
+ p_ptr->publ.usr_handle = usr_handle;
+ p_ptr->publ.max_pkt = MAX_PKT_DEFAULT;
p_ptr->publ.ref = ref;
msg = &p_ptr->publ.phdr;
msg_init(msg, DATA_LOW, TIPC_NAMED_MSG, TIPC_OK, LONG_H_SIZE, 0);
<at> <at> -248,11 +250,9 <at> <at> u32 tipc_createport_raw(void *usr_handle
msg_set_importance(msg,importance);
p_ptr->last_in_seqno = 41;
p_ptr->sent = 1;
- p_ptr->publ.usr_handle = usr_handle;
INIT_LIST_HEAD(&p_ptr->wait_list);
INIT_LIST_HEAD(&p_ptr->subscription.nodesub_list);
p_ptr->congested_link = NULL;
- p_ptr->max_pkt = MAX_PKT_DEFAULT;
p_ptr->dispatcher = dispatcher;
p_ptr->wakeup = wakeup;
p_ptr->user_port = NULL;
<at> <at> -1243,7 +1243,7 <at> <at> int tipc_connect2port(u32 ref, struct ti
res = TIPC_OK;
exit:
tipc_port_unlock(p_ptr);
- p_ptr->max_pkt = tipc_link_get_max_pkt(peer->node, ref);
+ p_ptr->publ.max_pkt = tipc_link_get_max_pkt(peer->node, ref);
return res;
}
diff --git a/net/tipc/port.h b/net/tipc/port.h
index 7ef4d64..674bd89 100644
--- a/net/tipc/port.h
+++ b/net/tipc/port.h
<at> <at> -81,7 +81,6 <at> <at> struct user_port {
* <at> acked:
* <at> publications: list of publications for port
* <at> pub_count: total # of publications port has made during its lifetime
- * <at> max_pkt: maximum packet size "hint" used when building messages sent by port
* <at> probing_state:
* <at> probing_interval:
* <at> last_in_seqno:
<at> <at> -102,7 +101,6 <at> <at> struct port {
u32 acked;
struct list_head publications;
u32 pub_count;
- u32 max_pkt;
u32 probing_state;
u32 probing_interval;
u32 last_in_seqno;
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index e3c5a98..f94e179 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
<at> <at> -607,23 +607,24 <at> <at> exit:
static int send_stream(struct kiocb *iocb, struct socket *sock,
struct msghdr *m, size_t total_len)
{
+ struct tipc_port *tport;
struct msghdr my_msg;
struct iovec my_iov;
struct iovec *curr_iov;
int curr_iovlen;
char __user *curr_start;
+ u32 hdr_size;
int curr_left;
int bytes_to_send;
int bytes_sent;
int res;
- if (likely(total_len <= TIPC_MAX_USER_MSG_SIZE))
- return send_packet(iocb, sock, m, total_len);
-
- /* Can only send large data streams if already connected */
+ /* Handle special cases where there is no connection */
if (unlikely(sock->state != SS_CONNECTED)) {
- if (sock->state == SS_DISCONNECTING)
+ if (sock->state == SS_UNCONNECTED)
+ return send_packet(iocb, sock, m, total_len);
+ else if (sock->state == SS_DISCONNECTING)
return -EPIPE;
else
return -ENOTCONN;
<at> <at> -648,17 +649,25 <at> <at> static int send_stream(struct kiocb *ioc
my_msg.msg_name = NULL;
bytes_sent = 0;
+ tport = tipc_sk(sock->sk)->p;
+ hdr_size = msg_hdr_sz(&tport->phdr);
+
while (curr_iovlen--) {
curr_start = curr_iov->iov_base;
curr_left = curr_iov->iov_len;
while (curr_left) {
- bytes_to_send = (curr_left < TIPC_MAX_USER_MSG_SIZE)
- ? curr_left : TIPC_MAX_USER_MSG_SIZE;
+ bytes_to_send = tport->max_pkt - hdr_size;
+ if (bytes_to_send > TIPC_MAX_USER_MSG_SIZE)
+ bytes_to_send = TIPC_MAX_USER_MSG_SIZE;
+ if (curr_left < bytes_to_send)
+ bytes_to_send = curr_left;
my_iov.iov_base = curr_start;
my_iov.iov_len = bytes_to_send;
if ((res = send_packet(iocb, sock, &my_msg, 0)) < 0) {
- return bytes_sent ? bytes_sent : res;
+ if (bytes_sent != 0)
+ res = bytes_sent;
+ return res;
}
curr_left -= bytes_to_send;
curr_start += bytes_to_send;
--
1.3.3
From nobody Mon Sep 17 00:00:00 2001
From: Allan Stephens <allan.stephens <at> windriver.com>
Date: Mon, 14 May 2007 15:09:03 -0400
Subject: [PATCH] [TIPC]: Improved support for Ethernet traffic filtering
This patch simplifies TIPC's Ethernet receive routine to take
advantage of information already present in each incoming sk_buff
indicating whether the packet was explicitly sent to the interface,
has been broadcast to all interfaces, or was picked up because the
interface is in promiscous mode.
This new approach also fixes the problem of TIPC accepting unwanted
traffic through UML's multicast-based Ethernet interfaces (which
deliver traffic in a promiscuous manner even if the interface is
not configured to be promiscuous).
Signed-off-by: Allan Stephens <allan.stephens <at> windriver.com>
---
net/tipc/eth_media.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
bd59148890a2de1b0daf779da8efb4f564f501b0
diff --git a/net/tipc/eth_media.c b/net/tipc/eth_media.c
index 67bb29b..db7943d 100644
--- a/net/tipc/eth_media.c
+++ b/net/tipc/eth_media.c
<at> <at> -2,7 +2,7 <at> <at>
* net/tipc/eth_media.c: Ethernet bearer support for TIPC
*
* Copyright (c) 2001-2006, Ericsson AB
- * Copyright (c) 2005-2006, Wind River Systems
+ * Copyright (c) 2005-2007, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
<at> <at> -87,6 +87,9 <at> <at> static int send_msg(struct sk_buff *buf,
/**
* recv_msg - handle incoming TIPC message from an Ethernet interface
*
+ * Accept only packets explicitly sent to this node, or broadcast packets;
+ * ignores packets sent using Ethernet multicast, and traffic sent to other
+ * nodes (which can happen if interface is running in promiscuous mode).
* Routine truncates any Ethernet padding/CRC appended to the message,
* and ensures message size matches actual length
*/
<at> <at> -98,9 +101,7 <at> <at> static int recv_msg(struct sk_buff *buf,
u32 size;
if (likely(eb_ptr->bearer)) {
- if (likely(!dev->promiscuity) ||
- !memcmp(skb_mac_header(buf), dev->dev_addr, ETH_ALEN) ||
- !memcmp(skb_mac_header(buf), dev->broadcast, ETH_ALEN)) {
+ if (likely(buf->pkt_type <= PACKET_BROADCAST)) {
size = msg_size((struct tipc_msg *)buf->data);
skb_trim(buf, size);
if (likely(buf->len == size)) {
--
1.3.3
From nobody Mon Sep 17 00:00:00 2001
From: Allan Stephens <allan.stephens <at> windriver.com>
Date: Mon, 14 May 2007 16:23:07 -0400
Subject: [PATCH] [TIPC]: Use standard socket "not implemented" routines
This patch modifies TIPC's socket API to utilize existing
generic routines to indicate unsupported operations, rather
than adding similar TIPC-specific routines.
Signed-off-by: Allan Stephens <allan.stephens <at> windriver.com>
---
net/tipc/socket.c | 53 +++++++++++++----------------------------------------
1 files changed, 13 insertions(+), 40 deletions(-)
3bc51ca9988b6830ceb93e090129e82aa9e56c01
diff --git a/net/tipc/socket.c b/net/tipc/socket.c
index 45832fb..e3c5a98 100644
--- a/net/tipc/socket.c
+++ b/net/tipc/socket.c
<at> <at> -2,7 +2,7 <at> <at>
* net/tipc/socket.c: TIPC socket API
*
* Copyright (c) 2001-2006, Ericsson AB
- * Copyright (c) 2004-2006, Wind River Systems
+ * Copyright (c) 2004-2007, Wind River Systems
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
<at> <at> -1600,33 +1600,6 <at> <at> static int getsockopt(struct socket *soc
}
/**
- * Placeholders for non-implemented functionality
- *
- * Returns error code (POSIX-compliant where defined)
- */
-
-static int ioctl(struct socket *s, u32 cmd, unsigned long arg)
-{
- return -EINVAL;
-}
-
-static int no_mmap(struct file *file, struct socket *sock,
- struct vm_area_struct *vma)
-{
- return -EINVAL;
-}
-static ssize_t no_sendpage(struct socket *sock, struct page *page,
- int offset, size_t size, int flags)
-{
- return -EINVAL;
-}
-
-static int no_skpair(struct socket *s1, struct socket *s2)
-{
- return -EOPNOTSUPP;
-}
-
-/**
* Protocol switches for the various types of TIPC sockets
*/
<at> <at> -1636,19 +1609,19 <at> <at> static struct proto_ops msg_ops = {
.release = release,
.bind = bind,
.connect = connect,
- .socketpair = no_skpair,
+ .socketpair = sock_no_socketpair,
.accept = accept,
.getname = get_name,
.poll = poll,
- .ioctl = ioctl,
+ .ioctl = sock_no_ioctl,
.listen = listen,
.shutdown = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg = send_msg,
.recvmsg = recv_msg,
- .mmap = no_mmap,
- .sendpage = no_sendpage
+ .mmap = sock_no_mmap,
+ .sendpage = sock_no_sendpage
};
static struct proto_ops packet_ops = {
<at> <at> -1657,19 +1630,19 <at> <at> static struct proto_ops packet_ops = {
.release = release,
.bind = bind,
.connect = connect,
- .socketpair = no_skpair,
+ .socketpair = sock_no_socketpair,
.accept = accept,
.getname = get_name,
.poll = poll,
- .ioctl = ioctl,
+ .ioctl = sock_no_ioctl,
.listen = listen,
.shutdown = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg = send_packet,
.recvmsg = recv_msg,
- .mmap = no_mmap,
- .sendpage = no_sendpage
+ .mmap = sock_no_mmap,
+ .sendpage = sock_no_sendpage
};
static struct proto_ops stream_ops = {
<at> <at> -1678,19 +1651,19 <at> <at> static struct proto_ops stream_ops = {
.release = release,
.bind = bind,
.connect = connect,
- .socketpair = no_skpair,
+ .socketpair = sock_no_socketpair,
.accept = accept,
.getname = get_name,
.poll = poll,
- .ioctl = ioctl,
+ .ioctl = sock_no_ioctl,
.listen = listen,
.shutdown = shutdown,
.setsockopt = setsockopt,
.getsockopt = getsockopt,
.sendmsg = send_stream,
.recvmsg = recv_stream,
- .mmap = no_mmap,
- .sendpage = no_sendpage
+ .mmap = sock_no_mmap,
+ .sendpage = sock_no_sendpage
};
static struct net_proto_family tipc_family_ops = {
--
--
1.3.3
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
tipc-discussion mailing list
tipc-discussion <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
Ciao,
// Randy
>
> Regards,
> Al
>
>> -----Original Message-----
>> From: tipc-discussion-bounces <at> lists.sourceforge.net
>> [mailto:tipc-discussion-bounces <at> lists.sourceforge.net] On
>> Behalf Of Stephens, Allan
>> Sent: Monday, April 30, 2007 11:16 AM
>> To: Randy Macleod; tipc-discussion <at> lists.sourceforge.net
>> Subject: Re: [tipc-discussion] tipc and routing.
>>
>> Hi Randy:
>>
>> Your requirement to allow TIPC traffic to be directed over a
>> specific path is a tricky one to address, since it violates
>> the "transparent"
>> nature of TIPC's addressing scheme. On the other hand, it
>> looks like something that TIPC users may benefit from (or, in
>> your case, require), so we should definitely take a stab at
>> trying to figure out how to do this ...
>>
>> The first solution you propose (associating certain TIPC
>> names with a specific link) runs into conflict with some
>> changes I'm planning on making later this year which are
>> designed to improve the performance of TIPC, especially in
>> multi-cluster network scenarios. Once implemented, there
>> will only be a single link between any pair of network nodes,
>> even when there are multiple paths between them; this will
>> eliminate the need for TIPC's complex link switchover logic,
>> open the door to better loadsharing of traffic over multiple
>> interfaces, and provide better performance and reliability
>> for inter-cluster message traffic.
>>
>> The second solution you propose sounds more feasible. (i.e.
>> I can't think of any objections to it off the top of my
>> head.) It has the benefit of being a general purpose
>> solution that might also address scenarios that have come up
>> in the past where users want to provide a VLAN-like
>> capability for TIPC that guarantees that traffic on two
>> different TIPC networks is isolated to its own network. On
>> the other hand, it may be overkill for your purposes since
>> you only seem to want to support two types of traffic
>> (control and data).
>>
>> I'll have to think a bit more about alternative solutions.
>> (I'm wondering if we could solve this requirement by treating
>> it as a "quality of service" issue, rather than a routing
>> issue?) Unfortunately, I'm pretty busy right now preparing
>> for the TIPC 1.7.3 release, so I haven't got a lot of cycles
>> to spare at the moment; things should be better in a couple of weeks.
>>
>> Regards,
>> Al
>>
>>> -----Original Message-----
>>> From: tipc-discussion-bounces <at> lists.sourceforge.net
>>> [mailto:tipc-discussion-bounces <at> lists.sourceforge.net] On Behalf Of
>>> Randy Macleod
>>> Sent: Thursday, April 26, 2007 5:37 PM
>>> To: tipc-discussion <at> lists.sourceforge.net
>>> Subject: Re: [tipc-discussion] tipc and routing.
>>>
>>> Hummm,
>>>
>>> No one is answering...
>>> I'll try again with another suggestion.
>>>
>>> Randy Macleod wrote:
>>>> Hi,
>>>>
>>>> A group that I'm working with wants to run TIPC on two
>>> separate networks:
>>>> net-A - slow/ low bandwidth (control)
>>>> net-B - fast/high bandwidth (payload)
>>>>
>>>> All nodes in the system will be connected to both networks
>>> like this:
>>>>
>>>> ---------------------------------- net-A
>>>> | | | |
>>>> | | | |
>>>> Node1 Node2 Node3 Node4
>>>> | | | |
>>>> | | | |
>>>> ---------------------------------- net-B
>>>>
>>> ...
>>>> I tried to fit this request into the multi-cluster/routing node
>>>> framework but since each node in a TIPC cluster and only
>>> have a single
>>>> Zone.Cluster.Node identifier,
>>> CAN only have a single Zone.Cluster.Node identifier,
>>>> that doesn't work well.
>>> Another other way of solving this problem is to have TWO
>> instances of
>>> TIPC running on each system giving each instance a
>> different netid and
>>> a different set of network interfaces to use.
>>>
>>> Right now you can't load tipc twice but that could be changed by
>>> eliminating global variable in the code for instance.
>>>
>>> Applications would have to use another address family to associate
>>> sockets with one TIPC instance or another.
>>>
>>> Does that interest anyone?
>>>
>>> Has anyone solved this issue in another way?
>>>
>>> Thanks for any feedback,
>>>
>>> // Randy
>>>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
RSS Feed