UNCLASSIFIED Following up on this - I was not releasing the buffer from the application. However in trying to test this again, I get an error from OcpiWorker.cxx (controlOperation), where it raises a PORT_NOT_CONNECTED error (0xD) during the call to app.start. I have two workers, one producing data and sending to a second worker. The external port is attached to the output port of the second worker, which aleters the test data slightly and sends it on. This is the same setup (as far as I can tell) that I had before, which worked (my bug aside). Has there been any change to the external port code that could cause this?
The DataTransport::Port::finalize function is called twice: 1. mine.role=1, flow=0, m_data->output=0 2. mine.role=0, flow=0, m_data->output=1 In both cases the function appears to complete, with "c.m_openCircuit = false", however when the Worker::controlOperation function is called, (port ordinal = 1 and the optionally connected ports = 0), it fails the port->definitionComplete() call and raises the exception. Nigel -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, 3 April 2012 11:57 PM To: [email protected] Subject: opencpi_dev Digest, Vol 24, Issue 1 Send opencpi_dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of opencpi_dev digest..." Today's Topics: 1. Getting data from workers into application [SEC=UNCLASSIFIED] (Merritt, Nigel (Contractor)) 2. Re: About dramStatus (Shepard Siegel) 3. Re: Getting data from workers into application [SEC=UNCLASSIFIED] (James Kulp) 4. Re: About dramStatus (Albert Kwon) 5. Re: About dramStatus (Shepard Siegel) ---------------------------------------------------------------------- Message: 1 Date: Tue, 3 Apr 2012 15:27:13 +0930 From: "Merritt, Nigel (Contractor)" <[email protected]> To: <[email protected]> Subject: [opencpi_dev] Getting data from workers into application [SEC=UNCLASSIFIED] Message-ID: <f92472a1995d1042bf9897ebfbe7221d0280d...@ednex513.dsto.defence.gov.au> Content-Type: text/plain; charset="us-ascii" UNCLASSIFIED Gents, I have been looking at ways of getting streaming data into the application (where it could be displayed and/or processed in some way). Using external ports seems problematic since polling does not capture every buffer (at least not in the test I created). Is there an existing way of doing this that does not involve external ports, or are there plans for some method to be implmented in the future? I am considering using a socket based (e.g. TCP) protocol to pass this data (which removes any concern as to where the application is running and is platform independant) and would like to know if this is a waste of time or whether I have missed something with external ports. Thanks, Nigel IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/private.cgi/opencpi_dev-opencpi.org/attachment s/20120403/d5a5da13/attachment-0001.htm> ------------------------------ Message: 2 Date: Tue, 3 Apr 2012 07:11:00 -0400 From: Shepard Siegel <[email protected]> To: Albert Kwon <[email protected]> Cc: [email protected] Subject: Re: [opencpi_dev] About dramStatus Message-ID: <CAMMLSKBy2a48BrY-ok0PHc+7CoDin=rk4yf5z0xjkcphn9w...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" See lines 133-135 https://github.com/ShepardSiegel/ocpi/blob/master/bsv/wrk/DramServer_v6. bsv The only bit that matters is bit 0. The rest are for debug and may or may not be present based upon hasDebugLogic Be sure to wait a second or two after the reset->unreset->initialize->start sequence before looking, as read-capture training takes a while and we have not yet made that long wait built into initialize (as it should be). Look at testSeq9* if you are unsure of the sequence, e.g. https://github.com/ShepardSiegel/ocpi/blob/master/bin/testSeq9b2 Please let me know if that was your issue. -Shep On Tue, Apr 3, 2012 at 1:05 AM, Albert Kwon <[email protected]> wrote: > Hi Shep, > > I have a quick question about dramStatus variable in DramServer_v6.bsv: > is initComplete.read supposed to be 1 when DRAM is ready? > When I get the value for dramStatus, it is always 16, which seems > like it means appFull = 1, and everything else is 0. > If so, how can I make sure that it is 1? > > Thanks, > Albert > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/private.cgi/opencpi_dev-opencpi.org/attachment s/20120403/a6e57710/attachment-0001.htm> ------------------------------ Message: 3 Date: Tue, 03 Apr 2012 08:26:32 -0400 From: James Kulp <[email protected]> To: [email protected] Subject: Re: [opencpi_dev] Getting data from workers into application [SEC=UNCLASSIFIED] Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Hi Nigel, External ports should capture every buffer. The polling just returns NULL when there is no buffer ready. When it returns != NULL, you have a buffer, that you must put (output) or release (input) after filling/using it. If you can show this is somehow not reliable, its a bug that would be high priority. You could certainly use external ports in a simple (local) app that communicated over sockets to others. Another approach would be to extend the scope of the OpenCPI app to include components running on other computers across the network. Then the networking would be just an OpenCPI transport between components, and should be either automatically selected, or require "protocol=ocpi-socket-rdma". Unfortunately, the tricks to doing this is not well documented. We intend to have xml app support for this over the next month or so. The idea is to complete the support for remote containers so you can simply assign workers to containers on other machines. I.e. there is a way to run OpenCPI apps with software containers in different processes, either on the same machine or different network-connected machines. Our "plumbing" between processes can use OFED/Infiniband, sockets, or (when in the same system) shared memory buffers (zero copy). The partially missing piece is the top down management of the containers running in separate processes. Cheers, Jim On 4/3/12 1:57 AM, Merritt, Nigel (Contractor) wrote: > > *UNCLASSIFIED* > > Gents, > I have been looking at ways of getting streaming data into the > application (where it could be displayed and/or processed in some way). > > Using external ports seems problematic since polling does not capture > every buffer (at least not in the test I created). > > Is there an existing way of doing this that does not involve external > ports, or are there plans for some method to be implmented in the future? > > I am considering using a socket based (e.g. TCP) protocol to pass this > data (which removes any concern as to where the application is running > and is platform independant) and would like to know if this is a waste > of time or whether I have missed something with external ports. > > Thanks, > > Nigel > > *IMPORTANT*: This email remains the property of the Department of > Defence and is subject to the jurisdiction of section 70 of the Crimes > Act 1914. If you have received this email in error, you are requested > to contact the sender and delete the email. > > > > _______________________________________________ > opencpi_dev mailing list > [email protected] > http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/private.cgi/opencpi_dev-opencpi.org/attachment s/20120403/1ce48324/attachment-0001.htm> ------------------------------ Message: 4 Date: Tue, 03 Apr 2012 10:03:16 -0400 From: Albert Kwon <[email protected]> To: Shepard Siegel <[email protected]> Cc: [email protected] Subject: Re: [opencpi_dev] About dramStatus Message-ID: <[email protected]> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" What is the equivalent of this when I'm using the c++ code (a code like testRpl)? Do I have to use swctl? Thanks, Albert On 04/03/2012 07:11 AM, Shepard Siegel wrote: > See lines 133-135 > https://github.com/ShepardSiegel/ocpi/blob/master/bsv/wrk/DramServer_v > 6.bsv > > The only bit that matters is bit 0. > The rest are for debug and may or may not be present based upon > hasDebugLogic > > Be sure to wait a second or two after the > reset->unreset->initialize->start sequence before looking, as > read-capture training takes a while and we have not yet made that long > wait built into initialize (as it should be). > > Look at testSeq9* if you are unsure of the sequence, e.g. > https://github.com/ShepardSiegel/ocpi/blob/master/bin/testSeq9b2 > > Please let me know if that was your issue. > > -Shep > > > > On Tue, Apr 3, 2012 at 1:05 AM, Albert Kwon <[email protected] > <mailto:[email protected]>> wrote: > > Hi Shep, > > I have a quick question about dramStatus variable in > DramServer_v6.bsv: is initComplete.read supposed to be 1 when DRAM > is ready? > When I get the value for dramStatus, it is always 16, which > seems like it means appFull = 1, and everything else is 0. > If so, how can I make sure that it is 1? > > Thanks, > Albert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/private.cgi/opencpi_dev-opencpi.org/attachment s/20120403/f9b95d0d/attachment-0001.htm> ------------------------------ Message: 5 Date: Tue, 3 Apr 2012 10:26:39 -0400 From: Shepard Siegel <[email protected]> To: Albert Kwon <[email protected]> Cc: [email protected] Subject: Re: [opencpi_dev] About dramStatus Message-ID: <CAMMLSKDoNCpm18rTT3X2Om2L=x7f0uhqn1yhdhtfmeqhssk...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" You should just be able to start the worker and (after the time for training); use it. For the moment, it would not be a bad idea to check that bit 0 of status is set. In the future, the training will take place on the initialize->start transition; and then the wait for training will be signaled by the delayed return of the START OK Control Op response. -Shep On Tue, Apr 3, 2012 at 10:03 AM, Albert Kwon <[email protected]> wrote: > What is the equivalent of this when I'm using the c++ code (a code > like testRpl)? Do I have to use swctl? > > Thanks, > Albert > > > > On 04/03/2012 07:11 AM, Shepard Siegel wrote: > > See lines 133-135 > https://github.com/ShepardSiegel/ocpi/blob/master/bsv/wrk/DramServer_v > 6.bsv > > The only bit that matters is bit 0. > The rest are for debug and may or may not be present based upon > hasDebugLogic > > Be sure to wait a second or two after the > reset->unreset->initialize->start sequence before looking, as > reset->unreset->initialize->read-capture > training takes a while and we have not yet made that long wait built > into initialize (as it should be). > > Look at testSeq9* if you are unsure of the sequence, e.g. > https://github.com/ShepardSiegel/ocpi/blob/master/bin/testSeq9b2 > > Please let me know if that was your issue. > > -Shep > > > > On Tue, Apr 3, 2012 at 1:05 AM, Albert Kwon <[email protected]>wrote: > >> Hi Shep, >> >> I have a quick question about dramStatus variable in >> DramServer_v6.bsv: is initComplete.read supposed to be 1 when DRAM is ready? >> When I get the value for dramStatus, it is always 16, which seems >> like it means appFull = 1, and everything else is 0. >> If so, how can I make sure that it is 1? >> >> Thanks, >> Albert >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.opencpi.org/private.cgi/opencpi_dev-opencpi.org/attachment s/20120403/f6841eb1/attachment.htm> ------------------------------ _______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org End of opencpi_dev Digest, Vol 24, Issue 1 ****************************************** IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. _______________________________________________ opencpi_dev mailing list [email protected] http://lists.opencpi.org/listinfo.cgi/opencpi_dev-opencpi.org
