Re: [gem5-dev] Packet ID messages in the protobuf packet trace format
Hi Gabe, You can already get the master ID through the request pointer of the packet (pkt->req->masterId()). But you're right, currently even if you use something like the master ID to populate the ID field, unless you keep track of more information you can't know where the packets in the trace originated from. I think adding a message that maps all IDs to a string description would make sense. If for example you decide to use the master ID in the trace then that new message can map the master ID to the its SimObject name. This would be unnecessary if you use the PC or the taskId but having this new message in the trace would be optional. Nikos On 15 September 2017 at 20:30, Gabe Blackwrote: > I wouldn't mind adding an explicit master ID field to the packet, but > that's not actually what I'm asking about. I'm suggesting adding a whole > new message type (like the header messages vs the request messages) which > describes what a particular ID represents. Obviously we don't want to send > something like system.cpu0.itlb with every access, but that's way more > useful than just the number 2, for instance. I'd like to embed a mapping > between those in the trace rather than having to dump the table through > some other means and to keep that alongside the trace for later translation. > > Gabe > > On Fri, Sep 15, 2017 at 1:49 AM, Andreas Hansson > wrote: > >> Hi Gabe, >> >> The pkt_id field was intentionally left up to the user to populate as they >> see fit. Master ID, stream ID, or PC as in the case of the mem_probe used >> by the CommMonitor. If you think there is need for another ID, then by all >> means we should add it. The question is, could you use the ID that is >> already there? >> >> If we change the format I agree we should make the field optional to not >> deprecate old traces. >> >> Andreas >> >> On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black" >> wrote: >> >> >Hi folks. I'd like to propose adding a new type of message to the >> >packet.proto format used for protobuf memory traces. >> > >> >Currently, packet IDs are opaque numbers which in some hand wavy way >> >"identify" a packet, presumably to say where that packet came from >> >(instruction, bus master, etc.) Currently there is no in-channel way to >> >map >> >those numbers to something more useful like an object name. What are >> >people's thoughs as far as adding a new message type which would provide >> >that information? Off the top of my head, it would make sense to have a >> >single message per ID, and to have a single "string" type field which >> >would >> >be used to describe the meaning of the ID in whatever way was appropriate. >> > >> >I haven't thought through the specifics very much, so suggestions would be >> >very appreciated. Currently I've got a hacky side-channel way to preserve >> >that information, but it would be less fragile and inconvenient if that >> >was >> >preserved directly in the trace itself. >> > >> >Also, would this warrant a new file format version number, or would the >> >fact that the additional messages can be ignored with no ill effect let us >> >keep it at the same number? >> > >> >Gabe >> >___ >> >gem5-dev mailing list >> >gem5-dev@gem5.org >> >http://m5sim.org/mailman/listinfo/gem5-dev >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> ___ >> gem5-dev mailing list >> gem5-dev@gem5.org >> http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Packet ID messages in the protobuf packet trace format
I wouldn't mind adding an explicit master ID field to the packet, but that's not actually what I'm asking about. I'm suggesting adding a whole new message type (like the header messages vs the request messages) which describes what a particular ID represents. Obviously we don't want to send something like system.cpu0.itlb with every access, but that's way more useful than just the number 2, for instance. I'd like to embed a mapping between those in the trace rather than having to dump the table through some other means and to keep that alongside the trace for later translation. Gabe On Fri, Sep 15, 2017 at 1:49 AM, Andreas Hanssonwrote: > Hi Gabe, > > The pkt_id field was intentionally left up to the user to populate as they > see fit. Master ID, stream ID, or PC as in the case of the mem_probe used > by the CommMonitor. If you think there is need for another ID, then by all > means we should add it. The question is, could you use the ID that is > already there? > > If we change the format I agree we should make the field optional to not > deprecate old traces. > > Andreas > > On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black" > wrote: > > >Hi folks. I'd like to propose adding a new type of message to the > >packet.proto format used for protobuf memory traces. > > > >Currently, packet IDs are opaque numbers which in some hand wavy way > >"identify" a packet, presumably to say where that packet came from > >(instruction, bus master, etc.) Currently there is no in-channel way to > >map > >those numbers to something more useful like an object name. What are > >people's thoughs as far as adding a new message type which would provide > >that information? Off the top of my head, it would make sense to have a > >single message per ID, and to have a single "string" type field which > >would > >be used to describe the meaning of the ID in whatever way was appropriate. > > > >I haven't thought through the specifics very much, so suggestions would be > >very appreciated. Currently I've got a hacky side-channel way to preserve > >that information, but it would be less fragile and inconvenient if that > >was > >preserved directly in the trace itself. > > > >Also, would this warrant a new file format version number, or would the > >fact that the additional messages can be ignored with no ill effect let us > >keep it at the same number? > > > >Gabe > >___ > >gem5-dev mailing list > >gem5-dev@gem5.org > >http://m5sim.org/mailman/listinfo/gem5-dev > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
Re: [gem5-dev] Packet ID messages in the protobuf packet trace format
Hi Gabe, The pkt_id field was intentionally left up to the user to populate as they see fit. Master ID, stream ID, or PC as in the case of the mem_probe used by the CommMonitor. If you think there is need for another ID, then by all means we should add it. The question is, could you use the ID that is already there? If we change the format I agree we should make the field optional to not deprecate old traces. Andreas On 12/09/2017, 00:24, "gem5-dev on behalf of Gabe Black"wrote: >Hi folks. I'd like to propose adding a new type of message to the >packet.proto format used for protobuf memory traces. > >Currently, packet IDs are opaque numbers which in some hand wavy way >"identify" a packet, presumably to say where that packet came from >(instruction, bus master, etc.) Currently there is no in-channel way to >map >those numbers to something more useful like an object name. What are >people's thoughs as far as adding a new message type which would provide >that information? Off the top of my head, it would make sense to have a >single message per ID, and to have a single "string" type field which >would >be used to describe the meaning of the ID in whatever way was appropriate. > >I haven't thought through the specifics very much, so suggestions would be >very appreciated. Currently I've got a hacky side-channel way to preserve >that information, but it would be less fragile and inconvenient if that >was >preserved directly in the trace itself. > >Also, would this warrant a new file format version number, or would the >fact that the additional messages can be ignored with no ill effect let us >keep it at the same number? > >Gabe >___ >gem5-dev mailing list >gem5-dev@gem5.org >http://m5sim.org/mailman/listinfo/gem5-dev IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
[gem5-dev] Packet ID messages in the protobuf packet trace format
Hi folks. I'd like to propose adding a new type of message to the packet.proto format used for protobuf memory traces. Currently, packet IDs are opaque numbers which in some hand wavy way "identify" a packet, presumably to say where that packet came from (instruction, bus master, etc.) Currently there is no in-channel way to map those numbers to something more useful like an object name. What are people's thoughs as far as adding a new message type which would provide that information? Off the top of my head, it would make sense to have a single message per ID, and to have a single "string" type field which would be used to describe the meaning of the ID in whatever way was appropriate. I haven't thought through the specifics very much, so suggestions would be very appreciated. Currently I've got a hacky side-channel way to preserve that information, but it would be less fragile and inconvenient if that was preserved directly in the trace itself. Also, would this warrant a new file format version number, or would the fact that the additional messages can be ignored with no ill effect let us keep it at the same number? Gabe ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev