Re: [tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

[Aki Van Ness via tcpdump-workers]

--- Begin Message ---
On Sun, Oct 25, 2020 at 2:05 AM Guy Harris  wrote:
>
> On Oct 21, 2020, at 1:56 PM, Aki Van Ness via tcpdump-workers 
>  wrote:
>
> > I'm working on a project that plans to store PCI and PCI-Express
> > packets in the pcapng format as that's the most appropriate storage
> > format and I really rather not roll something custom.
> >
> > As such what are thoughts on adding Link-Layer types for PCI, PCI-X,
> > and PCI-Express?
>
> It seems reasonable, given that we have USB, Infiniband, and the DisplayPort 
> AUX channel.
>
> > And would you want to group all versions of PCI, PCI-X, and
> > PCI-Express together or have them be their own values?
>
> Would each version need its own LINKTYPE_ value, or would a single metadata 
> header and payload suffice for all versions of PCI, all versions of PCI-X, 
> and all versions of PCIe?  From a quick look at the Wikipedia pages for 
> those, for what that's worth, they changes for each seem to be at the 
> physical layer, with full or at least significant backwards compatibility, 
> so, other than additional bits of metadata, would LINKTYPE_PCI, 
> LINKTYPE_PCI_X, and LINKTYPE_PCI_EXPRESS suffice?
>
> I'm assuming that the metadata would be different between PCI, PCI-X, and 
> PCIe.

Yeah, so having a LINKTYPE_PCI, LINKTYPE_PCI_X, and LINKTYPE_PCI_E
would work, seeing as they are different enough to not be compatible
with each other.

As for the inter-version having common metadata then the content would
be fine, as long as the metadata could store the version of the
protocol. While they are mostl backwards compatible some versions add
/ remove commands or registers. So being able to interpret additional
metadata depending on the protocol version would be beneficial.

At least that's how I see it and how I think it makes the most sense.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

[Guy Harris via tcpdump-workers]

--- Begin Message ---
On Oct 21, 2020, at 1:56 PM, Aki Van Ness via tcpdump-workers 
 wrote:

> I'm working on a project that plans to store PCI and PCI-Express
> packets in the pcapng format as that's the most appropriate storage
> format and I really rather not roll something custom.
> 
> As such what are thoughts on adding Link-Layer types for PCI, PCI-X,
> and PCI-Express?

It seems reasonable, given that we have USB, Infiniband, and the DisplayPort 
AUX channel.

> And would you want to group all versions of PCI, PCI-X, and
> PCI-Express together or have them be their own values?

Would each version need its own LINKTYPE_ value, or would a single metadata 
header and payload suffice for all versions of PCI, all versions of PCI-X, and 
all versions of PCIe?  From a quick look at the Wikipedia pages for those, for 
what that's worth, they changes for each seem to be at the physical layer, with 
full or at least significant backwards compatibility, so, other than additional 
bits of metadata, would LINKTYPE_PCI, LINKTYPE_PCI_X, and LINKTYPE_PCI_EXPRESS 
suffice?

I'm assuming that the metadata would be different between PCI, PCI-X, and PCIe.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

[Aki Van Ness via tcpdump-workers]

--- Begin Message ---
On Sat, Oct 24, 2020 at 5:32 PM Michael Richardson  wrote:
>
>
> Aki Van Ness  wrote:
> > Yeah it might be possible to use something like a single DLT. The issue
> > I can possibly forsee with that is PCI, PCI-X, and PCI-Express are all
> > slightly different enough to be a pain to group together into a single
> > structure.
>
> > It might be better to have either each type be its own DLT or if it
> > must be one DLT a layered approach with a meta-header of sorts that
> > just describes some of the generic information about the link, like
> > it's type, etc. then have a sub-section whose interpretation is
> > dependent on the link type.
>
> > I'm more partial towards the former than the latter personally, but I
> > understand not wanting to add a bunch of DLTs at once.
>
> If you prefer to use three/four DLTs, that's probably not a problem.
> If you wind up needing 20, then a distinguished union is probably a better
> solution.  (uhm. "distinguished union" seems not the be term I want)
> A layered solution.
>
> https://github.com/the-tcpdump-group/libpcap/blob/master/doc/DLT_ALLOCATE_HOWTO.md
>

Okay, that sounds fair.

Would the best thing for me to do is to just spin up a PR for libpcap
to add the DLTs / Link types as PoC and get feedback there?
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

[Aki Van Ness via tcpdump-workers]

--- Begin Message ---
On Thu, Oct 22, 2020 at 7:38 PM Michael Richardson  wrote:
>
>
> Aki Van Ness via tcpdump-workers  wrote:
> > I'm working on a project that plans to store PCI and PCI-Express
> > packets in the pcapng format as that's the most appropriate storage
> > format and I really rather not roll something custom.
>
> > As such what are thoughts on adding Link-Layer types for PCI, PCI-X,
> > and PCI-Express?
>
> Yes, you could do that.
> pcapng can handle a mix of different DLTs
> (pcap can not).
>
> It seems that they might be sufficiently similar that a single DLT might suit
> you.   Maybe you just want to build a header that accomodates a typical set
> of meta data.
>
> I imagine you'd have things like: PCI cycle type (read, write, configuration,
> IO, memory), read/write, address, any burst count, who is mastering, etc.
>
> The bulk of the content would be data transfered.
>

Yeah it might be possible to use something like a single DLT. The
issue I can possibly forsee with that is PCI, PCI-X, and PCI-Express
are all slightly different enough to be a pain to group together into
a single structure.

It might be better to have either each type be its own DLT or if it
must be one DLT a layered approach with a meta-header of sorts that
just describes some of the generic information about
the link, like it's type, etc. then have a sub-section whose
interpretation is dependent on the link type.

I'm more partial towards the former than the latter personally, but I
understand not wanting to add a bunch of DLTs at once.

> > And would you want to group all versions of PCI, PCI-X, and
> > PCI-Express together or have them be their own values?
>
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works|IoT architect   [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] [RFC] Addition of link-layer header types for PCI, PCI-X, and PCI-Express

[Aki Van Ness via tcpdump-workers]

--- Begin Message ---
Hello,

I'm working on a project that plans to store PCI and PCI-Express
packets in the pcapng format as that's the most appropriate storage
format and I really rather not roll something custom.

As such what are thoughts on adding Link-Layer types for PCI, PCI-X,
and PCI-Express?

And would you want to group all versions of PCI, PCI-X, and
PCI-Express together or have them be their own values?

Seeing as the following are all the individual specs for the lot:

PCI:
 * 1.0
 * 2.0
 * 3.0
PCI-X:
 * 1.0
 * 2.0
PCI-Express:
 * 1.0
 * 2.0
 * 3.0
 * 4.0
 * 5.0
 * 6.0

I know they are not strictly networking, but seeing as USB is already
in the list I figure that it can't hurt to add them.

The standards for the link-layers are all on
 but as an average person it's
almost near impossible to get your hands on them due to how
prohibitively expensive they are.


So what are peoples thoughts on this? Any recommended way to go about it?
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers