Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
Jon, I remembered I had ever given an ack for the series. Probably i forgot to send my ack. Anyway, I had spent time looking at all patches, as a result, no any issue was found during the review. This is very nice indeed. Thanks! Sent from my iPhone > On 17 Jan 2017, at 11:06 PM, Jon Maloy wrote: > > Thanks Partha. Any viewpoints form Ying? Otherwise I'll send it in tomorrow. > > ///jon > > >> -Original Message- >> From: Parthasarathy Bhuvaragan >> Sent: Tuesday, 17 January, 2017 09:35 >> To: Jon Maloy ; >> tipc-discussion@lists.sourceforge.net; >> Ying Xue >> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as >> transport option for multicast >> >>> On 01/16/2017 03:13 PM, Jon Maloy wrote: >>> >>> >>>> -Original Message- >>>> From: Parthasarathy Bhuvaragan >>>> Sent: Monday, 16 January, 2017 05:20 >>>> To: Jon Maloy ; tipc- >> discuss...@lists.sourceforge.net; >>>> Ying Xue >>>> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast >>>> as >>>> transport option for multicast >>>> >>>>> On 01/13/2017 04:18 PM, Jon Maloy wrote: >>>>> >>>>> >>>>>> -----Original Message- >>>>>> From: Parthasarathy Bhuvaragan >>>>>> Sent: Friday, 13 January, 2017 04:24 >>>>>> To: Jon Maloy ; tipc- >>>> discuss...@lists.sourceforge.net; >>>>>> Ying Xue >>>>>> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce >>>>>> replicast as >>>>>> transport option for multicast >>>>>> >>>>>>> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote: >>>>>>> Hi Jon, >>>>>>> >>>>>>> Added some minor comments inline in this patch, apart from that the >>>>>>> major concern is the following: >>>>>>> >>>>>>> All my tests which passed before this patch, fails while sending >>>>>>> multicast to a receiver on own node. >>>>>>> >>>>>>> With this patch, we increase the likelyhood of receive buffer overflow >>>>>>> if the sender & receivers are running on the same host as we bypass the >>>>>>> link layer completely. I confirmed this with some traces in >>>>>>> filter_rcv(). >>>>>>> >>>>>>> If I add another multicast listener running on another node, this >>>>>>> pacifies the sender (put the sender to sleep at link congestion) and >>>>>>> relatively slow link layer reduces the buffer overflow. >>>>>>> >>>>>>> We need to find a way reduce the aggressiveness of the sender. >>>>>>> We want users to be transparent about the location of the services, so >>>>>>> we should to provide similar charecteristics regardless of the service >>>>>>> location. >>>>>>> >>>>>> Jon, running ptts sever and client on a standalone node without your >>>>>> updates failed. So in that aspect, iam ok with this patch. >>>>>> >>>>>> If the ethernet bearer lacks broadcast ability, then neighbor discovery >>>>>> will not work. So do we intend to introduce support to add ethernet >>>>>> peers manually as we do for udp bearers? otherwise we can never use >>>>>> replicast for non udp bearers. >>>>> >>>>> I believe all Ethernet implementations, even overlay networks, provide >> some >>>> form of broadcast, or in lack thereof, an emulated broadcast. >>>>> So, discovery should work, but it will be very inefficient when we do link >>>> broadcast, because tipc will think that genuine Ethernet broadcast is >> supported. >>>>> We actually need some way to find out what kind of "Ethernet" we are >>>> attached to, e.g. VXLAN, so that the "bcast supported" flag can be set >> correctly. >>>>> I wonder if that if possible, or if it has to be configured. >>>>> >>>> I assumed that, but thanks for the clarification. I infer from your >>>> statement that its the User, who shall configure this per socket in case >>>> tipc is running over some kind of ov
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
Thanks Partha. Any viewpoints form Ying? Otherwise I'll send it in tomorrow. ///jon > -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Tuesday, 17 January, 2017 09:35 > To: Jon Maloy ; tipc-discussion@lists.sourceforge.net; > Ying Xue > Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as > transport option for multicast > > On 01/16/2017 03:13 PM, Jon Maloy wrote: > > > > > >> -Original Message- > >> From: Parthasarathy Bhuvaragan > >> Sent: Monday, 16 January, 2017 05:20 > >> To: Jon Maloy ; tipc- > discuss...@lists.sourceforge.net; > >> Ying Xue > >> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast > >> as > >> transport option for multicast > >> > >> On 01/13/2017 04:18 PM, Jon Maloy wrote: > >>> > >>> > >>>> -Original Message- > >>>> From: Parthasarathy Bhuvaragan > >>>> Sent: Friday, 13 January, 2017 04:24 > >>>> To: Jon Maloy ; tipc- > >> discuss...@lists.sourceforge.net; > >>>> Ying Xue > >>>> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce > >>>> replicast as > >>>> transport option for multicast > >>>> > >>>> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote: > >>>>> Hi Jon, > >>>>> > >>>>> Added some minor comments inline in this patch, apart from that the > >>>>> major concern is the following: > >>>>> > >>>>> All my tests which passed before this patch, fails while sending > >>>>> multicast to a receiver on own node. > >>>>> > >>>>> With this patch, we increase the likelyhood of receive buffer overflow > >>>>> if the sender & receivers are running on the same host as we bypass the > >>>>> link layer completely. I confirmed this with some traces in > >>>>> filter_rcv(). > >>>>> > >>>>> If I add another multicast listener running on another node, this > >>>>> pacifies the sender (put the sender to sleep at link congestion) and > >>>>> relatively slow link layer reduces the buffer overflow. > >>>>> > >>>>> We need to find a way reduce the aggressiveness of the sender. > >>>>> We want users to be transparent about the location of the services, so > >>>>> we should to provide similar charecteristics regardless of the service > >>>>> location. > >>>>> > >>>> Jon, running ptts sever and client on a standalone node without your > >>>> updates failed. So in that aspect, iam ok with this patch. > >>>> > >>>> If the ethernet bearer lacks broadcast ability, then neighbor discovery > >>>> will not work. So do we intend to introduce support to add ethernet > >>>> peers manually as we do for udp bearers? otherwise we can never use > >>>> replicast for non udp bearers. > >>> > >>> I believe all Ethernet implementations, even overlay networks, provide > some > >> form of broadcast, or in lack thereof, an emulated broadcast. > >>> So, discovery should work, but it will be very inefficient when we do link > >> broadcast, because tipc will think that genuine Ethernet broadcast is > supported. > >>> We actually need some way to find out what kind of "Ethernet" we are > >> attached to, e.g. VXLAN, so that the "bcast supported" flag can be set > correctly. > >>> I wonder if that if possible, or if it has to be configured. > >>> > >> I assumed that, but thanks for the clarification. I infer from your > >> statement that its the User, who shall configure this per socket in case > >> tipc is running over some kind of overlay networks. Tipc has no > >> knowledge about the tunnel mechanisms used under the exposed bearers. > > > > No, I don't think that is a good option. I think it will be in only very > > special cases > the user will want to enforce replicast, (e.g., security, or if he know there > will > always be very few destinations), and those would not be related to the > deployment. > > > >> > >> In that case, its more logical if we set this as a node attribute and > >> the sockets inherit them? > >> Since the applications itself usually are agnost
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
On 01/16/2017 03:13 PM, Jon Maloy wrote: > > >> -Original Message- >> From: Parthasarathy Bhuvaragan >> Sent: Monday, 16 January, 2017 05:20 >> To: Jon Maloy ; >> tipc-discussion@lists.sourceforge.net; >> Ying Xue >> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as >> transport option for multicast >> >> On 01/13/2017 04:18 PM, Jon Maloy wrote: >>> >>> >>>> -Original Message- >>>> From: Parthasarathy Bhuvaragan >>>> Sent: Friday, 13 January, 2017 04:24 >>>> To: Jon Maloy ; tipc- >> discuss...@lists.sourceforge.net; >>>> Ying Xue >>>> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast >>>> as >>>> transport option for multicast >>>> >>>> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote: >>>>> Hi Jon, >>>>> >>>>> Added some minor comments inline in this patch, apart from that the >>>>> major concern is the following: >>>>> >>>>> All my tests which passed before this patch, fails while sending >>>>> multicast to a receiver on own node. >>>>> >>>>> With this patch, we increase the likelyhood of receive buffer overflow >>>>> if the sender & receivers are running on the same host as we bypass the >>>>> link layer completely. I confirmed this with some traces in filter_rcv(). >>>>> >>>>> If I add another multicast listener running on another node, this >>>>> pacifies the sender (put the sender to sleep at link congestion) and >>>>> relatively slow link layer reduces the buffer overflow. >>>>> >>>>> We need to find a way reduce the aggressiveness of the sender. >>>>> We want users to be transparent about the location of the services, so >>>>> we should to provide similar charecteristics regardless of the service >>>>> location. >>>>> >>>> Jon, running ptts sever and client on a standalone node without your >>>> updates failed. So in that aspect, iam ok with this patch. >>>> >>>> If the ethernet bearer lacks broadcast ability, then neighbor discovery >>>> will not work. So do we intend to introduce support to add ethernet >>>> peers manually as we do for udp bearers? otherwise we can never use >>>> replicast for non udp bearers. >>> >>> I believe all Ethernet implementations, even overlay networks, provide some >> form of broadcast, or in lack thereof, an emulated broadcast. >>> So, discovery should work, but it will be very inefficient when we do link >> broadcast, because tipc will think that genuine Ethernet broadcast is >> supported. >>> We actually need some way to find out what kind of "Ethernet" we are >> attached to, e.g. VXLAN, so that the "bcast supported" flag can be set >> correctly. >>> I wonder if that if possible, or if it has to be configured. >>> >> I assumed that, but thanks for the clarification. I infer from your >> statement that its the User, who shall configure this per socket in case >> tipc is running over some kind of overlay networks. Tipc has no >> knowledge about the tunnel mechanisms used under the exposed bearers. > > No, I don't think that is a good option. I think it will be in only very > special cases the user will want to enforce replicast, (e.g., security, or if > he know there will always be very few destinations), and those would not be > related to the deployment. > >> >> In that case, its more logical if we set this as a node attribute and >> the sockets inherit them? >> Since the applications itself usually are agnostic of the deployment >> environments, it's not correct to place the platform specific logic >> inside the application. > > I was thinking more of setting this as a configured bearer attribute, unless > we find a way to deduce it from the interface attributes. I just didn't see > this as part of this series, but it should be done. > >> >> I think you need to rephrase the commit message. I read the commit >> message as if we are introducing a complete link level broadcast service >> replacement. But that's incorrect, as still broadcast link for neighbor >> discovery. > > Yes. This is only an optimization for broadcast traffic, nit neighbor > discovery. > Thanks Jon for the clarification. You may add my tag for the e
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
> -Original Message- > From: Parthasarathy Bhuvaragan > Sent: Monday, 16 January, 2017 05:20 > To: Jon Maloy ; tipc-discussion@lists.sourceforge.net; > Ying Xue > Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as > transport option for multicast > > On 01/13/2017 04:18 PM, Jon Maloy wrote: > > > > > >> -Original Message- > >> From: Parthasarathy Bhuvaragan > >> Sent: Friday, 13 January, 2017 04:24 > >> To: Jon Maloy ; tipc- > discuss...@lists.sourceforge.net; > >> Ying Xue > >> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast > >> as > >> transport option for multicast > >> > >> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote: > >>> Hi Jon, > >>> > >>> Added some minor comments inline in this patch, apart from that the > >>> major concern is the following: > >>> > >>> All my tests which passed before this patch, fails while sending > >>> multicast to a receiver on own node. > >>> > >>> With this patch, we increase the likelyhood of receive buffer overflow > >>> if the sender & receivers are running on the same host as we bypass the > >>> link layer completely. I confirmed this with some traces in filter_rcv(). > >>> > >>> If I add another multicast listener running on another node, this > >>> pacifies the sender (put the sender to sleep at link congestion) and > >>> relatively slow link layer reduces the buffer overflow. > >>> > >>> We need to find a way reduce the aggressiveness of the sender. > >>> We want users to be transparent about the location of the services, so > >>> we should to provide similar charecteristics regardless of the service > >>> location. > >>> > >> Jon, running ptts sever and client on a standalone node without your > >> updates failed. So in that aspect, iam ok with this patch. > >> > >> If the ethernet bearer lacks broadcast ability, then neighbor discovery > >> will not work. So do we intend to introduce support to add ethernet > >> peers manually as we do for udp bearers? otherwise we can never use > >> replicast for non udp bearers. > > > > I believe all Ethernet implementations, even overlay networks, provide some > form of broadcast, or in lack thereof, an emulated broadcast. > > So, discovery should work, but it will be very inefficient when we do link > broadcast, because tipc will think that genuine Ethernet broadcast is > supported. > > We actually need some way to find out what kind of "Ethernet" we are > attached to, e.g. VXLAN, so that the "bcast supported" flag can be set > correctly. > > I wonder if that if possible, or if it has to be configured. > > > I assumed that, but thanks for the clarification. I infer from your > statement that its the User, who shall configure this per socket in case > tipc is running over some kind of overlay networks. Tipc has no > knowledge about the tunnel mechanisms used under the exposed bearers. No, I don't think that is a good option. I think it will be in only very special cases the user will want to enforce replicast, (e.g., security, or if he know there will always be very few destinations), and those would not be related to the deployment. > > In that case, its more logical if we set this as a node attribute and > the sockets inherit them? > Since the applications itself usually are agnostic of the deployment > environments, it's not correct to place the platform specific logic > inside the application. I was thinking more of setting this as a configured bearer attribute, unless we find a way to deduce it from the interface attributes. I just didn't see this as part of this series, but it should be done. > > I think you need to rephrase the commit message. I read the commit > message as if we are introducing a complete link level broadcast service > replacement. But that's incorrect, as still broadcast link for neighbor > discovery. Yes. This is only an optimization for broadcast traffic, nit neighbor discovery. ///jon > > Thanks for your patience, probably its just me getting confused with the > purpose of the change-sets. > > /Partha > > > ///jon > > > >> > >> /Partha > >> > >>> /Partha > >>> > >>> On 01/02/2017 03:34 PM, Parthasarathy Bhuvaragan wrote: > >>>> Hi jon, > >>>> > >>>> When I include this patch
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
On 01/13/2017 04:18 PM, Jon Maloy wrote: > > >> -Original Message- >> From: Parthasarathy Bhuvaragan >> Sent: Friday, 13 January, 2017 04:24 >> To: Jon Maloy ; >> tipc-discussion@lists.sourceforge.net; >> Ying Xue >> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as >> transport option for multicast >> >> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote: >>> Hi Jon, >>> >>> Added some minor comments inline in this patch, apart from that the >>> major concern is the following: >>> >>> All my tests which passed before this patch, fails while sending >>> multicast to a receiver on own node. >>> >>> With this patch, we increase the likelyhood of receive buffer overflow >>> if the sender & receivers are running on the same host as we bypass the >>> link layer completely. I confirmed this with some traces in filter_rcv(). >>> >>> If I add another multicast listener running on another node, this >>> pacifies the sender (put the sender to sleep at link congestion) and >>> relatively slow link layer reduces the buffer overflow. >>> >>> We need to find a way reduce the aggressiveness of the sender. >>> We want users to be transparent about the location of the services, so >>> we should to provide similar charecteristics regardless of the service >>> location. >>> >> Jon, running ptts sever and client on a standalone node without your >> updates failed. So in that aspect, iam ok with this patch. >> >> If the ethernet bearer lacks broadcast ability, then neighbor discovery >> will not work. So do we intend to introduce support to add ethernet >> peers manually as we do for udp bearers? otherwise we can never use >> replicast for non udp bearers. > > I believe all Ethernet implementations, even overlay networks, provide some > form of broadcast, or in lack thereof, an emulated broadcast. > So, discovery should work, but it will be very inefficient when we do link > broadcast, because tipc will think that genuine Ethernet broadcast is > supported. > We actually need some way to find out what kind of "Ethernet" we are attached > to, e.g. VXLAN, so that the "bcast supported" flag can be set correctly. > I wonder if that if possible, or if it has to be configured. > I assumed that, but thanks for the clarification. I infer from your statement that its the User, who shall configure this per socket in case tipc is running over some kind of overlay networks. Tipc has no knowledge about the tunnel mechanisms used under the exposed bearers. In that case, its more logical if we set this as a node attribute and the sockets inherit them? Since the applications itself usually are agnostic of the deployment environments, it's not correct to place the platform specific logic inside the application. I think you need to rephrase the commit message. I read the commit message as if we are introducing a complete link level broadcast service replacement. But that's incorrect, as still broadcast link for neighbor discovery. Thanks for your patience, probably its just me getting confused with the purpose of the change-sets. /Partha > ///jon > >> >> /Partha >> >>> /Partha >>> >>> On 01/02/2017 03:34 PM, Parthasarathy Bhuvaragan wrote: >>>> Hi jon, >>>> >>>> When I include this patch, ptts case 12 (multicast) fails when the >>>> client and server are running on the same node. >>>> >>>> /Partha >>>> >>>> On 12/22/2016 04:15 PM, Jon Maloy wrote: >>>>> TIPC multicast messages are currently carried over a reliable >>>>> 'broadcast link', making use of the underlying media's ability to >>>>> transport packets as L2 broadcast or IP multicast to all nodes in >>>>> the cluster. >>>>> >>>>> When the used bearer is lacking that ability, we can instead emulate >>>>> the broadcast service by relicating and sending the packets over as >>>>> many unicast links as needed to reach all identified destinations. >>>>> We now introduce a new TIPC link-level 'replicast' service that does >>>>> this. >>>>> >>>>> Signed-off-by: Jon Maloy >>>>> --- >>>>> net/tipc/bcast.c | 105 >> ++ >>>>> net/tipc/bcast.h | 3 +- >>>>> net/tipc/link.c | 8 - >>>>&
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
> -Original Message-
> From: Parthasarathy Bhuvaragan
> Sent: Friday, 13 January, 2017 04:24
> To: Jon Maloy ; tipc-discussion@lists.sourceforge.net;
> Ying Xue
> Subject: Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as
> transport option for multicast
>
> On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote:
> > Hi Jon,
> >
> > Added some minor comments inline in this patch, apart from that the
> > major concern is the following:
> >
> > All my tests which passed before this patch, fails while sending
> > multicast to a receiver on own node.
> >
> > With this patch, we increase the likelyhood of receive buffer overflow
> > if the sender & receivers are running on the same host as we bypass the
> > link layer completely. I confirmed this with some traces in filter_rcv().
> >
> > If I add another multicast listener running on another node, this
> > pacifies the sender (put the sender to sleep at link congestion) and
> > relatively slow link layer reduces the buffer overflow.
> >
> > We need to find a way reduce the aggressiveness of the sender.
> > We want users to be transparent about the location of the services, so
> > we should to provide similar charecteristics regardless of the service
> > location.
> >
> Jon, running ptts sever and client on a standalone node without your
> updates failed. So in that aspect, iam ok with this patch.
>
> If the ethernet bearer lacks broadcast ability, then neighbor discovery
> will not work. So do we intend to introduce support to add ethernet
> peers manually as we do for udp bearers? otherwise we can never use
> replicast for non udp bearers.
I believe all Ethernet implementations, even overlay networks, provide some
form of broadcast, or in lack thereof, an emulated broadcast.
So, discovery should work, but it will be very inefficient when we do link
broadcast, because tipc will think that genuine Ethernet broadcast is supported.
We actually need some way to find out what kind of "Ethernet" we are attached
to, e.g. VXLAN, so that the "bcast supported" flag can be set correctly.
I wonder if that if possible, or if it has to be configured.
///jon
>
> /Partha
>
> > /Partha
> >
> > On 01/02/2017 03:34 PM, Parthasarathy Bhuvaragan wrote:
> >> Hi jon,
> >>
> >> When I include this patch, ptts case 12 (multicast) fails when the
> >> client and server are running on the same node.
> >>
> >> /Partha
> >>
> >> On 12/22/2016 04:15 PM, Jon Maloy wrote:
> >>> TIPC multicast messages are currently carried over a reliable
> >>> 'broadcast link', making use of the underlying media's ability to
> >>> transport packets as L2 broadcast or IP multicast to all nodes in
> >>> the cluster.
> >>>
> >>> When the used bearer is lacking that ability, we can instead emulate
> >>> the broadcast service by replicating and sending the packets over as
> >>> many unicast links as needed to reach all identified destinations.
> >>> We now introduce a new TIPC link-level 'replicast' service that does
> >>> this.
> >>>
> >>> Signed-off-by: Jon Maloy
> >>> ---
> >>> net/tipc/bcast.c | 105
> ++
> >>> net/tipc/bcast.h | 3 +-
> >>> net/tipc/link.c | 8 -
> >>> net/tipc/msg.c| 17 +
> >>> net/tipc/msg.h| 9 +++--
> >>> net/tipc/node.c | 27 +-
> >>> net/tipc/socket.c | 27 +-
> >>> 7 files changed, 149 insertions(+), 47 deletions(-)
> >>>
> >>> diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
> >>> index 412d335..672e6ef 100644
> >>> --- a/net/tipc/bcast.c
> >>> +++ b/net/tipc/bcast.c
> >>> @@ -70,7 +70,7 @@ static struct tipc_bc_base *tipc_bc_base(struct net
> *net)
> >>>
> >>> int tipc_bcast_get_mtu(struct net *net)
> >>> {
> >>> - return tipc_link_mtu(tipc_bc_sndlink(net));
> >>> + return tipc_link_mtu(tipc_bc_sndlink(net)) - INT_H_SIZE;
> >>> }
> >>>
> >>> /* tipc_bcbase_select_primary(): find a bearer with links to all
> >>> destinations,
> >>> @@ -175,42 +175,101 @@ static void tipc_bcbase_xmit(struct net *net,
> struct sk_buff_head *xmitq)
> >>> __skb_queue_purge(&_xmitq);
> >>> }
> >>>
> >>> -/* tipc_bcast_
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
On 01/04/2017 06:05 PM, Parthasarathy Bhuvaragan wrote:
> Hi Jon,
>
> Added some minor comments inline in this patch, apart from that the
> major concern is the following:
>
> All my tests which passed before this patch, fails while sending
> multicast to a receiver on own node.
>
> With this patch, we increase the likelyhood of receive buffer overflow
> if the sender & receivers are running on the same host as we bypass the
> link layer completely. I confirmed this with some traces in filter_rcv().
>
> If I add another multicast listener running on another node, this
> pacifies the sender (put the sender to sleep at link congestion) and
> relatively slow link layer reduces the buffer overflow.
>
> We need to find a way reduce the aggressiveness of the sender.
> We want users to be transparent about the location of the services, so
> we should to provide similar charecteristics regardless of the service
> location.
>
Jon, running ptts sever and client on a standalone node without your
updates failed. So in that aspect, iam ok with this patch.
If the ethernet bearer lacks broadcast ability, then neighbor discovery
will not work. So do we intend to introduce support to add ethernet
peers manually as we do for udp bearers? otherwise we can never use
replicast for non udp bearers.
/Partha
> /Partha
>
> On 01/02/2017 03:34 PM, Parthasarathy Bhuvaragan wrote:
>> Hi jon,
>>
>> When I include this patch, ptts case 12 (multicast) fails when the
>> client and server are running on the same node.
>>
>> /Partha
>>
>> On 12/22/2016 04:15 PM, Jon Maloy wrote:
>>> TIPC multicast messages are currently carried over a reliable
>>> 'broadcast link', making use of the underlying media's ability to
>>> transport packets as L2 broadcast or IP multicast to all nodes in
>>> the cluster.
>>>
>>> When the used bearer is lacking that ability, we can instead emulate
>>> the broadcast service by replicating and sending the packets over as
>>> many unicast links as needed to reach all identified destinations.
>>> We now introduce a new TIPC link-level 'replicast' service that does
>>> this.
>>>
>>> Signed-off-by: Jon Maloy
>>> ---
>>> net/tipc/bcast.c | 105
>>> ++
>>> net/tipc/bcast.h | 3 +-
>>> net/tipc/link.c | 8 -
>>> net/tipc/msg.c| 17 +
>>> net/tipc/msg.h| 9 +++--
>>> net/tipc/node.c | 27 +-
>>> net/tipc/socket.c | 27 +-
>>> 7 files changed, 149 insertions(+), 47 deletions(-)
>>>
>>> diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
>>> index 412d335..672e6ef 100644
>>> --- a/net/tipc/bcast.c
>>> +++ b/net/tipc/bcast.c
>>> @@ -70,7 +70,7 @@ static struct tipc_bc_base *tipc_bc_base(struct net *net)
>>>
>>> int tipc_bcast_get_mtu(struct net *net)
>>> {
>>> - return tipc_link_mtu(tipc_bc_sndlink(net));
>>> + return tipc_link_mtu(tipc_bc_sndlink(net)) - INT_H_SIZE;
>>> }
>>>
>>> /* tipc_bcbase_select_primary(): find a bearer with links to all
>>> destinations,
>>> @@ -175,42 +175,101 @@ static void tipc_bcbase_xmit(struct net *net, struct
>>> sk_buff_head *xmitq)
>>> __skb_queue_purge(&_xmitq);
>>> }
>>>
>>> -/* tipc_bcast_xmit - deliver buffer chain to all nodes in cluster
>>> - *and to identified node local sockets
>>> +/* tipc_bcast_xmit - broadcast the buffer chain to all external nodes
>>> * @net: the applicable net namespace
>>> - * @list: chain of buffers containing message
>>> + * @pkts: chain of buffers containing message
>>> + * @cong_link_cnt: set to 1 if broadcast link is congested, otherwise 0
>>> * Consumes the buffer chain.
>>> - * Returns 0 if success, otherwise errno:
>>> -ELINKCONG,-EHOSTUNREACH,-EMSGSIZE
>>> + * Returns 0 if success, otherwise errno: -EHOSTUNREACH,-EMSGSIZE
>>> */
>>> -int tipc_bcast_xmit(struct net *net, struct sk_buff_head *list)
>>> +static int tipc_bcast_xmit(struct net *net, struct sk_buff_head *pkts,
>>> + u16 *cong_link_cnt)
>>> {
>>> struct tipc_link *l = tipc_bc_sndlink(net);
>>> - struct sk_buff_head xmitq, inputq, rcvq;
>>> + struct sk_buff_head xmitq;
>>> int rc = 0;
>>>
>>> - __skb_queue_head_init(&rcvq);
>>> __skb_queue_head_init(&xmitq);
>>> - skb_queue_head_init(&inputq);
>>> -
>>> - /* Prepare message clone for local node */
>>> - if (unlikely(!tipc_msg_reassemble(list, &rcvq)))
>>> - return -EHOSTUNREACH;
>>> -
>>> tipc_bcast_lock(net);
>>> if (tipc_link_bc_peers(l))
>>> - rc = tipc_link_xmit(l, list, &xmitq);
>>> + rc = tipc_link_xmit(l, pkts, &xmitq);
>>> tipc_bcast_unlock(net);
>>> + tipc_bcbase_xmit(net, &xmitq);
>>> + __skb_queue_purge(pkts);
>>> + if (rc == -ELINKCONG) {
>>> + *cong_link_cnt = 1;
>>> + rc = 0;
>>> + }
>>> + return rc;
>>> +}
>>>
>>> - /* Don't send to local node if adding to link failed */
>>> - if (unlikely(rc && (rc != -ELINKCONG))) {
>>> - __skb_queue_purge(&r
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
Hi Jon,
Added some minor comments inline in this patch, apart from that the
major concern is the following:
All my tests which passed before this patch, fails while sending
multicast to a receiver on own node.
With this patch, we increase the likelyhood of receive buffer overflow
if the sender & receivers are running on the same host as we bypass the
link layer completely. I confirmed this with some traces in filter_rcv().
If I add another multicast listener running on another node, this
pacifies the sender (put the sender to sleep at link congestion) and
relatively slow link layer reduces the buffer overflow.
We need to find a way reduce the aggressiveness of the sender.
We want users to be transparent about the location of the services, so
we should to provide similar charecteristics regardless of the service
location.
/Partha
On 01/02/2017 03:34 PM, Parthasarathy Bhuvaragan wrote:
> Hi jon,
>
> When I include this patch, ptts case 12 (multicast) fails when the
> client and server are running on the same node.
>
> /Partha
>
> On 12/22/2016 04:15 PM, Jon Maloy wrote:
>> TIPC multicast messages are currently carried over a reliable
>> 'broadcast link', making use of the underlying media's ability to
>> transport packets as L2 broadcast or IP multicast to all nodes in
>> the cluster.
>>
>> When the used bearer is lacking that ability, we can instead emulate
>> the broadcast service by replicating and sending the packets over as
>> many unicast links as needed to reach all identified destinations.
>> We now introduce a new TIPC link-level 'replicast' service that does
>> this.
>>
>> Signed-off-by: Jon Maloy
>> ---
>> net/tipc/bcast.c | 105
>> ++
>> net/tipc/bcast.h | 3 +-
>> net/tipc/link.c | 8 -
>> net/tipc/msg.c| 17 +
>> net/tipc/msg.h| 9 +++--
>> net/tipc/node.c | 27 +-
>> net/tipc/socket.c | 27 +-
>> 7 files changed, 149 insertions(+), 47 deletions(-)
>>
>> diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
>> index 412d335..672e6ef 100644
>> --- a/net/tipc/bcast.c
>> +++ b/net/tipc/bcast.c
>> @@ -70,7 +70,7 @@ static struct tipc_bc_base *tipc_bc_base(struct net *net)
>>
>> int tipc_bcast_get_mtu(struct net *net)
>> {
>> -return tipc_link_mtu(tipc_bc_sndlink(net));
>> +return tipc_link_mtu(tipc_bc_sndlink(net)) - INT_H_SIZE;
>> }
>>
>> /* tipc_bcbase_select_primary(): find a bearer with links to all
>> destinations,
>> @@ -175,42 +175,101 @@ static void tipc_bcbase_xmit(struct net *net, struct
>> sk_buff_head *xmitq)
>> __skb_queue_purge(&_xmitq);
>> }
>>
>> -/* tipc_bcast_xmit - deliver buffer chain to all nodes in cluster
>> - *and to identified node local sockets
>> +/* tipc_bcast_xmit - broadcast the buffer chain to all external nodes
>> * @net: the applicable net namespace
>> - * @list: chain of buffers containing message
>> + * @pkts: chain of buffers containing message
>> + * @cong_link_cnt: set to 1 if broadcast link is congested, otherwise 0
>> * Consumes the buffer chain.
>> - * Returns 0 if success, otherwise errno: -ELINKCONG,-EHOSTUNREACH,-EMSGSIZE
>> + * Returns 0 if success, otherwise errno: -EHOSTUNREACH,-EMSGSIZE
>> */
>> -int tipc_bcast_xmit(struct net *net, struct sk_buff_head *list)
>> +static int tipc_bcast_xmit(struct net *net, struct sk_buff_head *pkts,
>> + u16 *cong_link_cnt)
>> {
>> struct tipc_link *l = tipc_bc_sndlink(net);
>> -struct sk_buff_head xmitq, inputq, rcvq;
>> +struct sk_buff_head xmitq;
>> int rc = 0;
>>
>> -__skb_queue_head_init(&rcvq);
>> __skb_queue_head_init(&xmitq);
>> -skb_queue_head_init(&inputq);
>> -
>> -/* Prepare message clone for local node */
>> -if (unlikely(!tipc_msg_reassemble(list, &rcvq)))
>> -return -EHOSTUNREACH;
>> -
>> tipc_bcast_lock(net);
>> if (tipc_link_bc_peers(l))
>> -rc = tipc_link_xmit(l, list, &xmitq);
>> +rc = tipc_link_xmit(l, pkts, &xmitq);
>> tipc_bcast_unlock(net);
>> +tipc_bcbase_xmit(net, &xmitq);
>> +__skb_queue_purge(pkts);
>> +if (rc == -ELINKCONG) {
>> +*cong_link_cnt = 1;
>> +rc = 0;
>> +}
>> +return rc;
>> +}
>>
>> -/* Don't send to local node if adding to link failed */
>> -if (unlikely(rc && (rc != -ELINKCONG))) {
>> -__skb_queue_purge(&rcvq);
>> -return rc;
>> +/* tipc_rcast_xmit - replicate and send a message to given destination nodes
>> + * @net: the applicable net namespace
>> + * @pkts: chain of buffers containing message
>> + * @dests: list of destination nodes
>> + * @cong_link_cnt: returns number of congested links
>> + * @cong_links: returns identities of congested links
remove @cong_links
>> + * Returns 0 if success, otherwise errno
>> + */
>> +static int tipc_rcast_xmit(struct net *net, struct sk_buff_head *pkts,
>> + struct
Re: [tipc-discussion] [net-next v3 3/4] tipc: introduce replicast as transport option for multicast
Hi jon,
When I include this patch, ptts case 12 (multicast) fails when the
client and server are running on the same node.
/Partha
On 12/22/2016 04:15 PM, Jon Maloy wrote:
> TIPC multicast messages are currently carried over a reliable
> 'broadcast link', making use of the underlying media's ability to
> transport packets as L2 broadcast or IP multicast to all nodes in
> the cluster.
>
> When the used bearer is lacking that ability, we can instead emulate
> the broadcast service by replicating and sending the packets over as
> many unicast links as needed to reach all identified destinations.
> We now introduce a new TIPC link-level 'replicast' service that does
> this.
>
> Signed-off-by: Jon Maloy
> ---
> net/tipc/bcast.c | 105
> ++
> net/tipc/bcast.h | 3 +-
> net/tipc/link.c | 8 -
> net/tipc/msg.c| 17 +
> net/tipc/msg.h| 9 +++--
> net/tipc/node.c | 27 +-
> net/tipc/socket.c | 27 +-
> 7 files changed, 149 insertions(+), 47 deletions(-)
>
> diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
> index 412d335..672e6ef 100644
> --- a/net/tipc/bcast.c
> +++ b/net/tipc/bcast.c
> @@ -70,7 +70,7 @@ static struct tipc_bc_base *tipc_bc_base(struct net *net)
>
> int tipc_bcast_get_mtu(struct net *net)
> {
> - return tipc_link_mtu(tipc_bc_sndlink(net));
> + return tipc_link_mtu(tipc_bc_sndlink(net)) - INT_H_SIZE;
> }
>
> /* tipc_bcbase_select_primary(): find a bearer with links to all
> destinations,
> @@ -175,42 +175,101 @@ static void tipc_bcbase_xmit(struct net *net, struct
> sk_buff_head *xmitq)
> __skb_queue_purge(&_xmitq);
> }
>
> -/* tipc_bcast_xmit - deliver buffer chain to all nodes in cluster
> - *and to identified node local sockets
> +/* tipc_bcast_xmit - broadcast the buffer chain to all external nodes
> * @net: the applicable net namespace
> - * @list: chain of buffers containing message
> + * @pkts: chain of buffers containing message
> + * @cong_link_cnt: set to 1 if broadcast link is congested, otherwise 0
> * Consumes the buffer chain.
> - * Returns 0 if success, otherwise errno: -ELINKCONG,-EHOSTUNREACH,-EMSGSIZE
> + * Returns 0 if success, otherwise errno: -EHOSTUNREACH,-EMSGSIZE
> */
> -int tipc_bcast_xmit(struct net *net, struct sk_buff_head *list)
> +static int tipc_bcast_xmit(struct net *net, struct sk_buff_head *pkts,
> +u16 *cong_link_cnt)
> {
> struct tipc_link *l = tipc_bc_sndlink(net);
> - struct sk_buff_head xmitq, inputq, rcvq;
> + struct sk_buff_head xmitq;
> int rc = 0;
>
> - __skb_queue_head_init(&rcvq);
> __skb_queue_head_init(&xmitq);
> - skb_queue_head_init(&inputq);
> -
> - /* Prepare message clone for local node */
> - if (unlikely(!tipc_msg_reassemble(list, &rcvq)))
> - return -EHOSTUNREACH;
> -
> tipc_bcast_lock(net);
> if (tipc_link_bc_peers(l))
> - rc = tipc_link_xmit(l, list, &xmitq);
> + rc = tipc_link_xmit(l, pkts, &xmitq);
> tipc_bcast_unlock(net);
> + tipc_bcbase_xmit(net, &xmitq);
> + __skb_queue_purge(pkts);
> + if (rc == -ELINKCONG) {
> + *cong_link_cnt = 1;
> + rc = 0;
> + }
> + return rc;
> +}
>
> - /* Don't send to local node if adding to link failed */
> - if (unlikely(rc && (rc != -ELINKCONG))) {
> - __skb_queue_purge(&rcvq);
> - return rc;
> +/* tipc_rcast_xmit - replicate and send a message to given destination nodes
> + * @net: the applicable net namespace
> + * @pkts: chain of buffers containing message
> + * @dests: list of destination nodes
> + * @cong_link_cnt: returns number of congested links
> + * @cong_links: returns identities of congested links
> + * Returns 0 if success, otherwise errno
> + */
> +static int tipc_rcast_xmit(struct net *net, struct sk_buff_head *pkts,
> +struct tipc_nlist *dests, u16 *cong_link_cnt)
> +{
> + struct sk_buff_head _pkts;
> + struct u32_item *n, *tmp;
> + u32 dst, selector;
> +
> + selector = msg_link_selector(buf_msg(skb_peek(pkts)));
> + __skb_queue_head_init(&_pkts);
> +
> + list_for_each_entry_safe(n, tmp, &dests->list, list) {
> + dst = n->value;
> + if (!tipc_msg_pskb_copy(dst, pkts, &_pkts))
> + return -ENOMEM;
> +
> + /* Any other return value than -ELINKCONG is ignored */
> + if (tipc_node_xmit(net, &_pkts, dst, selector) == -ELINKCONG)
> + (*cong_link_cnt)++;
> }
> + return 0;
> +}
>
> - /* Broadcast to all nodes, inluding local node */
> - tipc_bcbase_xmit(net, &xmitq);
> - tipc_sk_mcast_rcv(net, &rcvq, &inputq);
> - __skb_queue_purge(list);
> +/* tipc_mcast_xmit - deliver message to indicated destination nodes
> + * and to identified node local sockets
> + * @net: the appli
