P1394 Mail Archive: P1394> EMAIL I mentioned in 1/12 telecon

P1394 Mail Archive: P1394> EMAIL I mentioned in 1/12 telecon

P1394> EMAIL I mentioned in 1/12 telecon

Gregory A. LeClair (gleclair@agentz.com)
Mon, 19 Jan 1998 22:59:24 -0800

This is the email I referred to during the telecon.

For those on 1394 PWG reflector who haven't seen this yet.....

Should 1394 PWG profile require/recommend the feature set of 1394a?

Comments?

------------------
Greg LeClair

-----Original Message-----
From: Jerry Hauck [SMTP:Jerry_Hauck@ccm.sc.intel.com]
Sent: Thursday, January 08, 1998 8:53 PM
To: stds-1394@ieee.org; 1394-architecture@1394TA.org; 1394ohci-l@austin.ibm.com
Cc: federico@unibrain.com; paull@otenet.gr; met@unibrain.com; zach@unibrain.com
Subject: Re: Clarifications & Suggestions

Dimitris,

Thank you for your time in submitting these issues for discussion.
I've embedded some personal comments below. As an unsolicited piece
of advice, I'd suggest that you may see better results from
categorizing your issues into related standards activities (OHCI vs
P1394a vs Bridging, etc.) and then posting just the pertinent
questions to the appropriate working reflector. Also, please be aware
the P1394a is making every effort to wrap things up and, as such, is
unlikely to consider any new proposal at this date. My intention is
not to discourage you ... I just simply wanted to set appropriate
expectations. Some of these ideas may be well suited for follow-on
1394 TA white papers, best known methods, etc.

Again, see some my two comments below.

Regards,

Jerry Hauck
Intel Corp.
(408) 765-5528
jerry_hauck@ccm.sc.intel.com

> Hello Everybody,
>
> I am working as a 1394 device driver developer at Unibrain
> (www.unibrain.com). Over the
> course of my work I have come up with a few questions and a few proposals
> for 1394, and
> I guess that this list is the proper place to lay them down.
>
> Here is a quick summary of the topics that I will discuss below:
> (1) CLARIFICATION: One or multiple talkers allowed on an isochronous
> channel?
> 1394-1995 and P1394a Draft 1.13 include contradicting references on this
> issue.
> (2) PROPOSAL: Broadcast Bus ID.
> (3) PROPOSAL: GUID to Physical ID map registers.
> (4) PROPOSAL: 2-Writes-Make-A-Read transaction.
> (5) PROPOSAL: OHCI Physical Lower Bound Register.
>
> ----------------------------------------------------------------------------
> ------------
> (1) CLARIFICATION: One or multiple talkers allowed on an isochronous
> channel?
>
> Can more than one nodes transmit on an isochronous channel (during
> different
> isochronous cycles)? If you read the references that I include below you
> will
> realise that you cannot be 100% certain (page numbers are as they appear
> on the printed documents):
>
> P1394a13, page 12:
> 2.2.13 channel: A relationship between a group of nodes, *talkers* and
> listeners.
> The group is identified by a number between zero and 63. Channel numbers
> are
> allocated co-operatively through isochronous resource management
> facilities.
>
> COMMENT: Notice the plural for *talkers*.
>
>
> P1394a13, page 101:
> For a given channel number, no more than one talker may transmit an
> isochronous
> stream packet with that channel number each isochronous period.
>
> COMMENT: Clearly such a statement would not be necessary if there is only
> one talker
> allowed for each channel.
>
>
> P1394a13, page 101:
> Multiple nodes may transmit asynchronous stream packets with the same
> channel
> number or the same node may transmit multiple asynchronous stream
> packets with
> the same channel number as often as desired, subject to arbitration
> fairness.
>
> COMMENT: Multiple talkers are permitted for asynchronous streams.
>
>
> P1394a13, page 112:
> DUPLICATE CHANNEL DETECTED (Optional). A stream packet was received with
> a channel
> number equal to one of the node's active, transmit isochronous channels.
>
> COMMENT: Does 'active' mean active during the current isochornous cycle or
> more
> generally configured for isochronous transmission?
>
>
> 1394-1995 (Draft 8.0v3), page 238, 8.4.2.4:
> If an isochronous resourse, either channel or bandwidth, cannot be
> reallocated,
> the Serial Bus node that owned the resources prior to the bus reset
> shall cause
> the corresponding isochronous talker to cease broadcast of isochronous
> packets.
>
> COMMENT: Now here we see a statement about a channel and its corresponding
> talker,
> not talkers. This statement clearly supposes that there is only
> one talker
> that should be instructed to cease its transmissions.
>
>
> 1394-1995 (Draft 8.0v3), page 240, 8.4.3:
> Owners of isochronous resources, either bandwidth or channel
> assignments, gain
> ownership of these resources through the procedures described in clauses
> 8.4.3.1
> and 8.4.3.2. Note that the owner of an isochronous resource need be
> neither
> *the* talker nor *a* listener for the channel in question.
>
> COMMENT: Note that it speaks about THE talker (clearly implies only one)
> and A listener (obviously implies many).
>
>
> OHCI Draft 1.0, Annex D.4 Isochronous Transmit, page 155:
> A bus reset does not affect the transmission of isochronous packets,
> which continue
> being transmitted for their assigned channels. It is software's
> responsibility to
> perform the necessary isochronous resource re-allocation and make any
> communication
> to the talker's and/or receivers' control registers.
>
> COMMENT: This also clearly implies one talker and multiple listeners.
>
>
> If you ask my opinion I would say that it sounds wiser and more reasonable
> to allow
> only one talker per isochronous channel. Here are some of the consequences
> of allowing
> multiple talkers:
>
> (*) The chip must monitor the cable for the channel numbers that have
> transmitted
> during the current isochronous cycle and avoid transmitting data for
> these channels
> during this cycle (the transmission would cause a DUPLICATE CHANNEL
> DETECTED error).
> This does not sound to my ears like being trivial (especially if there
> are DMA
> contexts configured for multiple channel transmissions).
>
> (*) It is not easy to share the bandwidth of a channel between many nodes.
> Indeed, a node might not get the chance to transmit at all if some node
> closer
> to the cycle master continuously transmits on the channel!!! That node
> would
> always win isochronous arbitration first.
> So there must be application logic involved in the whole story, for
> example a
> logical token passed around the talkers so that each can speak in turn.
> This
> involves extra programming complications (what will happen if the bus is
> split,
> or if the token gets corrupted) in order to save bandwidth (for example
> 5 instances
> of an application running on different nodes, that need to transmit at
> 10Mbps in
> turn one after the other, can use only 10Mbps instead of allocating a
> total of
> 50Mbps and utilizing only 10 at a time).
>
>
> Based on the contradicting references that I include above, I think that
> the issue
> deserves a clarification. Maybe it could be discussed at the P1394a working
> group
> meeting.

[Jerry Hauck] I actually do not find the references contradictory. When
referring to _isochronous_ streams, I belive all of the references cited above
are consistent. Only one isochronous talker per isochronous channel. P1394a
introduced the concept of _asynchronous_ streams. These streams allow multiple
talkers per channel. Hardware is not at all impacted. During the isochornous
period, links transmit the isochronous stream packets as normal. Higher layers
ensure that the channel numbers are unique and the DUPLICATE_CHANNEL detection
function can reveal if this is violated. During the asynchronous interval,
links can broadcast asynch stream packets which will have been assigned one or
more channel numbers all of which are distinct from the isoch channel numbers.
Multiple talkers are allowed on this distinct set of channels.

>
> ----------------------------------------------------------------------------
> ------------
> (2) PROPOSAL: Broadcast Bus ID.
>
> I think that it would be a good idea if apart from 0x3FF (the local bus
> ID) another
> bus ID is reserved for broadcasts that are intended not only for the local
> network,
> but for all 1394 networks attached through 1394 bridges. These broadcasts
> would cross
> 1394 bridges and reach all nodes whatsoever.
>
> The reason why this would be a good idea is that this way a node can very
> easily
> notify the whole 1394 world of significant events (the addition of a new
> printer, a
> change in address -see also below-). Instead of having all nodes
> continuously poll
> and cause significant traffic, the node in question can inform the world
> in one
> transmission.
>
> ----------------------------------------------------------------------------
> ------------
> (3) PROPOSAL: GUID to Physical ID map registers.
>
> The first activity that software will initiate after a bus reset is the
> discovery of
> the new physical IDs that nodes have acquired. A driver that presents a
> handle based
> API to an application will usually maintain some form of GUID-to-PhyID
> map. The
> handle is opened based on the GUID, but the actual transmissions are made
> with the PhyID.
> After a bus reset the driver will clear its GUID-to-PhyID map and try to
> reestablish
> the mappings by reading the Bus_Info_Block of the nodes present on the
> bus.
> This will cause significant traffic which can be avoided if we introduce
> the notion
> of GUID-to-PhyID map registers.
>
> This will be a reserved area in the 1394 address space, of size 1023*63*64
> bits.
> There will be one entry corresponding to each possible NodeID, for a total
> of
> 1023*63 entries. Each entry will be storing the EUI-64 of the node that
> currently
> holds the specific NodeID.
> This register map will be maintained at *all* nodes and can be possibly
> considered
> write-only (although this only makes little difference).
> After a bus reset each node clears its own register map, and broadcasts a
> write with
> its EUI-64 to the entry corresponding to its new Physical ID. This way on
> a bus with
> 20 nodes there will be 20 broadcast writes and everybody's mappings would
> be updated.
>
> Using the current non-solution each node would have to read the other 19
> nodes' GUIDs
> for a total of 19*19=361 reads and another 361 read responses, which is
> significantly
> more than the 20 64-bit broadcast writes.
>
> Moreover, if a node is communicating with some node on a remote 1394
> network (the
> driver would be obviously aware of that), it can broadcast the write using
> the
> broadcast bus ID mentioned above, so that the other node(s) are
> immediately informed
> of the address change without lost packets and timeouts.
> A node on a remote network cannot be informed of the bus reset on the
> local network.
> So apart from sending packets to a non-existent node, it could possibly
> send a few
> transactions to another node before realising that it is talking to
> another node,
> if at all! Things would be greatly simplified if the node would receive a
> packet
> implying the new GUID-to-PhyID mapping.
>
>
> ----------------------------------------------------------------------------
> ------------
> (4) PROPOSAL: 2-Writes-Make-A-Read transaction.
>
> I recently read on an IEEE journal about the 2-Writes-Make-A-Read model
> for bus reads.
> The author was saying the bus reads are a slow operation and could be
> replaced by two
> writes as follows: the requester writes to some control registers the
> offset and amount
> of data that it wants to read, and also a response buffer address. When
> the data is
> ready the responder performs a write operation to the buffer address
> provided by the
> requestor.
>
> Based on that we could introduce a similar transaction for asynchronous
> reads on the
> 1394 bus. The read is a packet containing source 1394 address, amount of
> data to read,
> and destination 1394 address. The data will be returned as a normal write
> transaction
> to this address.
>
> This could have great benefits, especially if coupled with the OHCI
> standard that
> specifies that transactions in the low 4GB can be performed directly. The
> reader sets
> up the response buffer at some available address in the low 4GB, and when
> the response
> arrives (as a write transaction) it is directly written at the destination
> buffer
> without any need for response mappings and buffer availability checks,
> ready
> to provide to the application without redundant data copies from a random
> response
> buffer to the application buffer (now the application buffer is set up as
> *the* response
> buffer).

[Jerry Hauck] I think OHCI already supports this (more or less). Most
usage models for OHCI I envision don't have the host using many (if
any) read requests. Instead, peripheral devices (or other OHCI's) are
programmed to push data into the Physical region of the local OHCI. I
think we can accomplish the efficiency and performance of your
suggestion by ensuring that SBP-2, IP over 1394, etc. all use the
concept of "bus-mastering" into OHCI. As such, the Asynch Rx Response
Queue will get very little usage in OHCI.

>
> But generally I think that such a model of operation would simplify the
> workings of
> 1394 at all levels, since there would only be one kind of transaction to
> deal with
> (writes, either simple or locked).
> ----------------------------------------------------------------------------
> ------------
> (5) PROPOSAL: OHCI Physical Lower Bound Register.
>
> Mapping the low 4GB of a node's 1394 address space to the host's low 4GB
> of physical
> memory is obviously a good idea but I think that it should be more
> strictly controlled,
> apart from a simple filter that permits or prohibits a node from direct
> physical access.
>
> Even if the node is a fully trusted node, access to all of the host
> physical memory can
> pause a serious security and stability threat.
>
> I would propose that the host controller can specify both the start and
> the end of the
> address range where direct physical access is allowed, instead of having
> the lower bound
> fixed at 48'h0 and only the upper bound specified in an optional register.
> This way the device driver running on a personal computer operating system
> can possibly
> reserve a physical address range as needed by the applications and only
> allow access
> to this range.
>
> Personally I would opt for several pairs of such registers to allow for
> maximum driver
> flexibility but I can live with one :-)
>
> ----------------------------------------------------------------------------
> ------------
>
> Well this is what I have to propose for discussion. May be these proposals
> should be
> made directly to a working group meeting, but I think it's better to
> discuss them
> here for a while first.
>
> I am looking forward to your responses.
>
> Sincerely Yours,
>
> ============================================================================
> ============
> Dimitris Staikos
> dstaikos@unibrain.com (Business mail only please),
> dstaikos@softlab.ntua.gr (Personal mail), ICQ UIN 169876 Top Jimmy
> Software Systems & Applications Chief Engineer, UniBrain,
> http://www.unibrain.com
> Diploma. El. & Computer Eng. National Technical University of Athens (NTUA)
>
> http://www.ntua.gr
> ============================================================================
> ============
> After all is said and done, there is usually more said than done.
> Some make it happen, some watch it happen, and some say, "what happened?"
> Each man with a new idea is a crank until the idea succeeds.
> Once the game is over, the king and the pawn go back into the same box.
> How a man plays a game shows something of his character, how he loses shows
> all of it.
> ============================================================================
> ============