Hi Hans,
Current MDS apitest only binary execution on one node.
It is easier if create IMM test case to make IMMD send broadcast big message.
I think we can create new ticket for this additional test.
Best Regards,
ThuanTr
-----Original Message-----
From: Hans Nordebäck <hans.nordeb...@ericsson.com>
Sent: Friday, May 3, 2019 2:45 PM
To: Thuan Tran <thuan.t...@dektech.com.au>; Minh Hon Chau
<minh.c...@dektech.com.au>; Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 0/1] Review Request for mds: support multicast fragmented
messages [#3033] V3
Hi Thuan,
ok, if we can add additional tests to the mds api test suite would be
good/Thanks HansN
-----Original Message-----
From: Tran Thuan <thuan.t...@dektech.com.au>
Sent: den 3 maj 2019 09:41
To: Hans Nordebäck <hans.nordeb...@ericsson.com>; Minh Hon Chau
<minh.c...@dektech.com.au>; Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 0/1] Review Request for mds: support multicast fragmented
messages [#3033] V3
Hi Hans,
I don't see this kind of test in mds apitests.
Best Regards,
ThuanTr
-----Original Message-----
From: Hans Nordebäck <hans.nordeb...@ericsson.com>
Sent: Friday, May 3, 2019 2:31 PM
To: Thuan Tran <thuan.t...@dektech.com.au>; Minh Hon Chau
<minh.c...@dektech.com.au>; Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 0/1] Review Request for mds: support multicast fragmented
messages [#3033] V3
Hi Thuan,
I'm reviewing the patch now. I haven't checked yet but do you know if the mds
apitests cover this case sending large multicast messages? /Thanks HansN
-----Original Message-----
From: Tran Thuan <thuan.t...@dektech.com.au>
Sent: den 2 maj 2019 05:56
To: Minh Hon Chau <minh.c...@dektech.com.au>; Vu Minh Nguyen
<vu.m.ngu...@dektech.com.au>; Hans Nordebäck <hans.nordeb...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 0/1] Review Request for mds: support multicast fragmented
messages [#3033] V3
Hi Hans,
Do you have any further comment?
Can we push the patch?
Best Regards,
ThuanTr
-----Original Message-----
From: Minh Hon Chau <minh.c...@dektech.com.au>
Sent: Friday, April 26, 2019 4:11 PM
To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; 'Hans Nordebäck'
<hans.nordeb...@ericsson.com>; 'Thuan Tran' <thuan.t...@dektech.com.au>
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 0/1] Review Request for mds: support multicast fragmented
messages [#3033] V3
Hi,
ack from me (code review)
Thanks
Minh
On 25/4/19 9:33 pm, Vu Minh Nguyen wrote:
> Hi Hans,
>
> Probably you were looking at code that included this Thuan's patch.
>
> In legacy code, only mdtm_sendto() is called inside the function
> mdtm_frag_and_send().
>
> Regards, Vu
>
>> -----Original Message-----
>> From: Hans Nordebäck <hans.nordeb...@ericsson.com>
>> Sent: Thursday, April 25, 2019 6:10 PM
>> To: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>; Thuan Tran
>> <thuan.t...@dektech.com.au>; Minh Hon Chau <minh.c...@dektech.com.au>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: RE: [PATCH 0/1] Review Request for mds: support multicast
>> fragmented messages [#3033] V3
>>
>>
>> Hi Vu,
>> It seems mdtm_mcast_sendto is used in mdtm_frag_and_send, at
>> MDS_SENDTYPE_BCAST/BR Hans -----Original Message-----
>> From: Vu Minh Nguyen <vu.m.ngu...@dektech.com.au>
>> Sent: den 25 april 2019 12:20
>> To: Hans Nordebäck <hans.nordeb...@ericsson.com>; Thuan Tran
>> <thuan.t...@dektech.com.au>; Minh Hon Chau <minh.c...@dektech.com.au>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: RE: [PATCH 0/1] Review Request for mds: support multicast
>> fragmented messages [#3033] V3
>>
>> Hi Hans,
>>
>> See my responses inline.
>>
>> Regards, Vu
>>
>>> -----Original Message-----
>>> From: Hans Nordebäck <hans.nordeb...@ericsson.com>
>>> Sent: Thursday, April 25, 2019 4:28 PM
>>> To: Thuan Tran <thuan.t...@dektech.com.au>; Vu Minh Nguyen
>>> <vu.m.ngu...@dektech.com.au>; Minh Hon Chau
>> <minh.c...@dektech.com.au>
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: Re: [PATCH 0/1] Review Request for mds: support multicast
>>> fragmented messages [#3033] V3
>>>
>>> Hi Vu and Thuan,
>>>
>>> a few question, is the text in the ticket description correct? E.g
>>> it says unicast is used if a multicast message is fragmented, (I
>>> think multicast still is used
>>>
>>> to send the fragments), this is what you mean with 2 different channels?
>>> (only one socket is used, BSRsock),
>> [Vu] Yes. Unicast is used to send fragmented messages. Here is the
>> current logic in case of sending a large package:
>> Iterate over destinations { // mcm_pvt_process_svc_bcast_common() @
>> mds_c_sndrcv.c
>> 1) Fragment the package // mdtm_frag_and_send() @ mds_dt_tipc.c
>> 2) Unicast to a specific adest // mdtm_sendto() @
>> mds_dt_tipc.c
>> 4) Continue with next adest
>> }
>>
>>> The problem stated is sending one large multicast message and then
>>> several smaller multicast messages, have you checked the
>>>
>>> fragment re-assembly part of the common code?
>> [Vu] Yes. At the receive side, if msg is fragmented, mds will not
>> forward to upper layer until all fragmented msgs are collected.
>> If the message is not fragmented, mds will transfer the msg to upper
>> right away.
>>
>> I checked with TIPC guys here, and he said that TIPC does not
>> guarantee the order if we send msgs in different channels (unicast vs mcast).
>>
>>> /BR Hans
>>>
>>>
>>> On 2019-04-24 13:06, thuan.tran wrote:
>>>> Summary: mds: support multicast fragmented messages [#3033] Review
>>>> request for Ticket(s): 3033 Peer Reviewer(s): Hans, Minh, Vu Pull
>>>> request to: *** LIST THE PERSON WITH PUSH ACCESS HERE *** Affected
>>>> branch(es): develop Development branch: ticket-3033 Base revision:
>>>> 7916ac316e86478c621c8359cf2aca4886288a38
>>>> Personal repository: git://git.code.sf.net/u/thuantr/review
>>>>
>>>> --------------------------------
>>>> Impacted area Impact y/n
>>>> --------------------------------
>>>> Docs n
>>>> Build system n
>>>> RPM/packaging n
>>>> Configuration files n
>>>> Startup scripts n
>>>> SAF services y
>>>> OpenSAF services n
>>>> Core libraries n
>>>> Samples n
>>>> Tests n
>>>> Other n
>>>>
>>>> NOTE: Patch(es) contain lines longer than 80 characers
>>>>
>>>> Comments (indicate scope for each "y" above):
>>>> ---------------------------------------------
>>>> N/A
>>>>
>>>> revision 568f09774f936506f5e05e03813fa572af0fe0d3
>>>> Author: thuan.tran <thuan.t...@dektech.com.au>
>>>> Date: Wed, 24 Apr 2019 17:54:25 +0700
>>>>
>>>> mds: support multicast fragmented messages [#3033]
>>>>
>>>> - Sender may send broadcast big messages (> 65K) then small
>>>> messages (<
>>> 65K).
>>>> Current MDS just loop via all destinations to unicast all
>>>> fragmented
>>> messages
>>>> to one by one destinations. But sending multicast non-fragment
>>>> messages
>>> to all
>>>> destinations. Therefor, receivers may get messages with incorrect
>>>> order, non-fragment messages may come before fragmented messages.
>>>> For example, it may lead to OUT OF ORDER for IMMNDs during IMMD
>> sync.
>>>> - Solution: support send multicast each fragmented messages to
>>>> avoid disorder of arrived broadcast messages.
>>>>
>>>>
>>>>
>>>> Complete diffstat:
>>>> ------------------
>>>> src/mds/mds_c_sndrcv.c | 3 +-
>>>> src/mds/mds_dt_tipc.c | 104
>>>> +++++++++++++++++++-------------------------
>>> -----
>>>> 2 files changed, 40 insertions(+), 67 deletions(-)
>>>>
>>>>
>>>> Testing Commands:
>>>> -----------------
>>>> N/A
>>>>
>>>> Testing, Expected Results:
>>>> --------------------------
>>>> N/A
>>>>
>>>> Conditions of Submission:
>>>> -------------------------
>>>> N/A
>>>>
>>>> Arch Built Started Linux distro
>>>> -------------------------------------------
>>>> mips n n
>>>> mips64 n n
>>>> x86 n n
>>>> x86_64 y y
>>>> powerpc n n
>>>> powerpc64 n n
>>>>
>>>>
>>>> Reviewer Checklist:
>>>> -------------------
>>>> [Submitters: make sure that your review doesn't trigger any
>>>> checkmarks!]
>>>>
>>>>
>>>> Your checkin has not passed review because (see checked entries):
>>>>
>>>> ___ Your RR template is generally incomplete; it has too many blank
>> entries
>>>> that need proper data filled in.
>>>>
>>>> ___ You have failed to nominate the proper persons for review and push.
>>>>
>>>> ___ Your patches do not have proper short+long header
>>>>
>>>> ___ You have grammar/spelling in your header that is unacceptable.
>>>>
>>>> ___ You have exceeded a sensible line length in your
>>> headers/comments/text.
>>>> ___ You have failed to put in a proper Trac Ticket # into your commits.
>>>>
>>>> ___ You have incorrectly put/left internal data in your comments/files
>>>> (i.e. internal bug tracking tool IDs, product names etc)
>>>>
>>>> ___ You have not given any evidence of testing beyond basic build tests.
>>>> Demonstrate some level of runtime or other sanity testing.
>>>>
>>>> ___ You have ^M present in some of your files. These have to be
>> removed.
>>>> ___ You have needlessly changed whitespace or added whitespace crimes
>>>> like trailing spaces, or spaces before tabs.
>>>>
>>>> ___ You have mixed real technical changes with whitespace and other
>>>> cosmetic code cleanup changes. These have to be separate commits.
>>>>
>>>> ___ You need to refactor your submission into logical chunks; there is
>>>> too much content into a single commit.
>>>>
>>>> ___ You have extraneous garbage in your review (merge commits etc)
>>>>
>>>> ___ You have giant attachments which should never have been sent;
>>>> Instead you should place your content in a public tree to be pulled.
>>>>
>>>> ___ You have too many commits attached to an e-mail; resend as
>> threaded
>>>> commits, or place in a public tree for a pull.
>>>>
>>>> ___ You have resent this content multiple times without a clear indication
>>>> of what has changed between each re-send.
>>>>
>>>> ___ You have failed to adequately and individually address all of the
>>>> comments and change requests that were proposed in the
>>>> initial
>> review.
>>>> ___ You have a misconfigured ~/.gitconfig file (i.e. user.name,
>>>> user.email
>>> etc)
>>>> ___ Your computer have a badly configured date and time; confusing the
>>>> the threaded patch review.
>>>>
>>>> ___ Your changes affect IPC mechanism, and you don't present any
>> results
>>>> for in-service upgradability test.
>>>>
>>>> ___ Your changes affect user manual and documentation, your patch
>> series
>>>> do not contain the patch that updates the Doxygen manual.
>>>>
>
>
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
