diff options
author | Jon Paul Maloy <jon.maloy@ericsson.com> | 2015-10-22 12:51:38 (GMT) |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2015-10-24 13:56:32 (GMT) |
commit | c1ab3f1dea3df566ad38caf98baf69c656679090 (patch) | |
tree | f62e1118dade62d290f0a5cfc418b355194da013 /.mailmap | |
parent | 323019069e8d96d87e9dba51f897060f94999821 (diff) | |
download | linux-c1ab3f1dea3df566ad38caf98baf69c656679090.tar.xz |
tipc: make struct tipc_link generic to support broadcast
Realizing that unicast is just a special case of broadcast, we also see
that we can go in the other direction, i.e., that modest changes to the
current unicast link can make it generic enough to support broadcast.
The following changes are introduced here:
- A new counter ("ackers") in struct tipc_link, to indicate how many
peers need to ack a packet before it can be released.
- A corresponding counter in the skb user area, to keep track of how
many peers a are left to ack before a buffer can be released.
- A new counter ("acked"), to keep persistent track of how far a peer
has acked at the moment, i.e., where in the transmission queue to
start updating buffers when the next ack arrives. This is to avoid
double acknowledgements from a peer, with inadvertent relase of
packets as a result.
- A more generic tipc_link_retrans() function, where retransmit starts
from a given sequence number, instead of the first packet in the
transmision queue. This is to minimize the number of retransmitted
packets on the broadcast media.
When the new functionality is taken into use in the next commits,
we expect it to have minimal effect on unicast mode performance.
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Reviewed-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions