HW communication debugging interface - ideas?

HW communication debugging interface - ideas?

[Jiri Pirko]

Hi Dave/all.

There is quite common for drivers to speak with HW using "packet-like"
messages. In our case, we put message into skb and push that out as
an ordinary packet. HW then sends us reply in a packet, similar to other
rx-ed packets.

It makes sense to monitor this communication. Not only for debugging
during development, but mainly for collecting data for error reports
from users.

Very cool usecase is to teach wireshark to parse this communication so
one can actually see online what is going on.

Now the question is, what is the correct way to expose this
communication to userspace. Naturally, this interface should be read-only.
Also, the interface should be generic enough so it can be used for all
drivers, including non-net drivers.

1) Special monitoring netdev.
Might make sense to use a separate netdev. Is is easy to tap the
communication. Driver would just create new netdev and push incoming and
outgoing messages there. Downside is that there would be needed to wrap the
messages with some metadata header, which seems quite odd.

2) generic Netlink (genl) interface. Easy to put metadata in, including the
device identificator (pci address). User then can use nlmon in order to
be able to use wireshark to see the netlink messages.

Looks like 2) might be viable, well-defined, generic interface to carry
this info. What do you think? Does this make sense?

Thanks!

Jiri

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Wed, Sep 30, 2015 at 03:51:41PM CEST, jiri@resnulli.us wrote:
>Hi Dave/all.
>
>There is quite common for drivers to speak with HW using "packet-like"
>messages. In our case, we put message into skb and push that out as
>an ordinary packet. HW then sends us reply in a packet, similar to other
>rx-ed packets.
>
>It makes sense to monitor this communication. Not only for debugging
>during development, but mainly for collecting data for error reports
>from users.
>
>Very cool usecase is to teach wireshark to parse this communication so
>one can actually see online what is going on.
>
>Now the question is, what is the correct way to expose this
>communication to userspace. Naturally, this interface should be read-only.
>Also, the interface should be generic enough so it can be used for all
>drivers, including non-net drivers.
>
>1) Special monitoring netdev.
>Might make sense to use a separate netdev. Is is easy to tap the
>communication. Driver would just create new netdev and push incoming and
>outgoing messages there. Downside is that there would be needed to wrap the
>messages with some metadata header, which seems quite odd.
>
>2) generic Netlink (genl) interface. Easy to put metadata in, including the
>device identificator (pci address). User then can use nlmon in order to
>be able to use wireshark to see the netlink messages.
>
>Looks like 2) might be viable, well-defined, generic interface to carry
>this info. What do you think? Does this make sense?
>
>Thanks!
>
>Jiri

Any ideas, anyone, Dave, please?

Thanks!

Re: HW communication debugging interface - ideas?

[David Miller]

From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 5 Oct 2015 10:54:06 +0200

> Any ideas, anyone, Dave, please?

I am very busy over the next few weeks and therefore it will take
me some time to look into this very deeply.

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 11:38:53AM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Mon, 5 Oct 2015 10:54:06 +0200
>
>> Any ideas, anyone, Dave, please?
>
>I am very busy over the next few weeks and therefore it will take
>me some time to look into this very deeply.

If you could spend like 5-10 minutes on this, that would be great. We would
like to start to implement this, but we are not sure which direction to
take. I'll owe you a beer then :)

Thanks!

RE: HW communication debugging interface - ideas?

[Rosen, Rami]

Hi, Jiri,

>In our case, we put message into skb and  ...

Just to be sure we are on the same page:

By "In our case" - I assume you are referring to the mlxsw Ethernet switch driver, right ? 

>we put message into skb and push that out as an ordinary packet. >HW then > sends us reply in a packet, similar to other rx-ed packets.

Are you referring here to messages of the EMAD protocol ?

Rami Rosen
Intel Corporation

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 11:54:38AM CEST, rami.rosen@intel.com wrote:
>Hi, Jiri,
>
>>In our case, we put message into skb and  ...
>
>Just to be sure we are on the same page:
>
>By "In our case" - I assume you are referring to the mlxsw Ethernet switch driver, right ? 

Yes.

>
>>we put message into skb and push that out as an ordinary packet. >HW then > sends us reply in a packet, similar to other rx-ed packets.
>
>Are you referring here to messages of the EMAD protocol ?

Yes.

>
>Rami Rosen
>Intel Corporation
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HW communication debugging interface - ideas?

[Thomas Graf]

On 09/30/15 at 03:51pm, Jiri Pirko wrote:
> 2) generic Netlink (genl) interface. Easy to put metadata in, including the
> device identificator (pci address). User then can use nlmon in order to
> be able to use wireshark to see the netlink messages.
> 
> Looks like 2) might be viable, well-defined, generic interface to carry
> this info. What do you think? Does this make sense?

+1 since we already have nlmon and Netlink is our standard
control plane protocol.

Re: HW communication debugging interface - ideas?

[Andrew Lunn]

> >Are you referring here to messages of the EMAD protocol ?

I know nothing about this protocol.....

Does it at least use standard Ethernet framing? Source and Destination
header and an EtherType which mean EMAD?

Marvell has a way to access registers of their switches using Ethernet
Frames, and they are valid frames with a specific EtherType. Linux
does not use them, but if it did, i would of thought passing them
along using the normal pcap interface would be trivial.

      Andrew

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>> >Are you referring here to messages of the EMAD protocol ?
>
>I know nothing about this protocol.....
>
>Does it at least use standard Ethernet framing? Source and Destination
>header and an EtherType which mean EMAD?

Yep, but that does not really matter. I believe we should find debugging
interface which is protocol agnostic. Just arbitrary messages
monitoring.


>
>Marvell has a way to access registers of their switches using Ethernet
>Frames, and they are valid frames with a specific EtherType. Linux
>does not use them, but if it did, i would of thought passing them
>along using the normal pcap interface would be trivial.
>
>      Andrew

Re: HW communication debugging interface - ideas?

[Andrew Lunn]

On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
> >> >Are you referring here to messages of the EMAD protocol ?
> >
> >I know nothing about this protocol.....
> >
> >Does it at least use standard Ethernet framing? Source and Destination
> >header and an EtherType which mean EMAD?
> 
> Yep, but that does not really matter. I believe we should find debugging
> interface which is protocol agnostic. Just arbitrary messages
> monitoring.

Hi Jiri

O.K, it is just that you mentioned wireshark. Passing the frames to
network interface taps would make this trivial.

	Andrew

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>> >> >Are you referring here to messages of the EMAD protocol ?
>> >
>> >I know nothing about this protocol.....
>> >
>> >Does it at least use standard Ethernet framing? Source and Destination
>> >header and an EtherType which mean EMAD?
>> 
>> Yep, but that does not really matter. I believe we should find debugging
>> interface which is protocol agnostic. Just arbitrary messages
>> monitoring.
>
>Hi Jiri
>
>O.K, it is just that you mentioned wireshark. Passing the frames to
>network interface taps would make this trivial.

That is true. But using netlink+nlmon would do the same.

Re: HW communication debugging interface - ideas?

[John Fastabend]

On 15-10-05 08:18 AM, Jiri Pirko wrote:
> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>
>>>> I know nothing about this protocol.....
>>>>
>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>> header and an EtherType which mean EMAD?
>>>
>>> Yep, but that does not really matter. I believe we should find debugging
>>> interface which is protocol agnostic. Just arbitrary messages
>>> monitoring.
>>
>> Hi Jiri
>>
>> O.K, it is just that you mentioned wireshark. Passing the frames to
>> network interface taps would make this trivial.
> 
> That is true. But using netlink+nlmon would do the same.

Also I guess if you go this direction you want to make it generic
enough for any drivers to use it to snoop software/firmware msgs. This
is common across many devices.

In the past though I've just used ethtool dump commands and some
"scripts" on top of this to debug devices. And when it got really
bad wrote some throw away code to debug my issue. I guess it might
be nice to have something in the kernel to improve this but have
you considered using the tracing features that already exist?

.John

> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastabend@gmail.com wrote:
>On 15-10-05 08:18 AM, Jiri Pirko wrote:
>> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>>
>>>>> I know nothing about this protocol.....
>>>>>
>>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>>> header and an EtherType which mean EMAD?
>>>>
>>>> Yep, but that does not really matter. I believe we should find debugging
>>>> interface which is protocol agnostic. Just arbitrary messages
>>>> monitoring.
>>>
>>> Hi Jiri
>>>
>>> O.K, it is just that you mentioned wireshark. Passing the frames to
>>> network interface taps would make this trivial.
>> 
>> That is true. But using netlink+nlmon would do the same.
>
>Also I guess if you go this direction you want to make it generic
>enough for any drivers to use it to snoop software/firmware msgs. This
>is common across many devices.

Yes, definitelly, this should be something generic to be usable for
every device type.


>
>In the past though I've just used ethtool dump commands and some
>"scripts" on top of this to debug devices. And when it got really
>bad wrote some throw away code to debug my issue. I guess it might
>be nice to have something in the kernel to improve this but have
>you considered using the tracing features that already exist?

Which ones do you have in mind?


>
>.John
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>

Re: HW communication debugging interface - ideas?

[John Fastabend]

On 15-10-05 08:35 AM, Jiri Pirko wrote:
> Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastabend@gmail.com wrote:
>> On 15-10-05 08:18 AM, Jiri Pirko wrote:
>>> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>>>
>>>>>> I know nothing about this protocol.....
>>>>>>
>>>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>>>> header and an EtherType which mean EMAD?
>>>>>
>>>>> Yep, but that does not really matter. I believe we should find debugging
>>>>> interface which is protocol agnostic. Just arbitrary messages
>>>>> monitoring.
>>>>
>>>> Hi Jiri
>>>>
>>>> O.K, it is just that you mentioned wireshark. Passing the frames to
>>>> network interface taps would make this trivial.
>>>
>>> That is true. But using netlink+nlmon would do the same.
>>
>> Also I guess if you go this direction you want to make it generic
>> enough for any drivers to use it to snoop software/firmware msgs. This
>> is common across many devices.
> 
> Yes, definitelly, this should be something generic to be usable for
> every device type.
> 
> 
>>
>> In the past though I've just used ethtool dump commands and some
>> "scripts" on top of this to debug devices. And when it got really
>> bad wrote some throw away code to debug my issue. I guess it might
>> be nice to have something in the kernel to improve this but have
>> you considered using the tracing features that already exist?
> 
> Which ones do you have in mind?
> 

I was thinking something like kprobes+bpf to dump a trace and
then a lua script in wireshark to parse the input and pretty
print it for users. This might get you good-enough support without
having to carry it around in the kernel just so we can debug
the devices. We could build some libs/pkgs around it in userspace
and get it published somewhere so we can all work on it together.

I suspect the primary users for this will be developers anyways
and maybe some users who have a real nasty bug.

> 
>>
>> .John
>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>

Re: HW communication debugging interface - ideas?

[Marcelo Ricardo Leitner]

On Wed, Sep 30, 2015 at 03:51:41PM +0200, Jiri Pirko wrote:
> Hi Dave/all.
> 
> There is quite common for drivers to speak with HW using "packet-like"
> messages. In our case, we put message into skb and push that out as
> an ordinary packet. HW then sends us reply in a packet, similar to other
> rx-ed packets.

Better sure than sorry so I'll ask. It's not possible for an application
to inject such skbs somehow, right?  Like, a guest, tied to a bridge,
tied to a port which ends up understanding these skbs.

...
> 2) generic Netlink (genl) interface. Easy to put metadata in, including the
> device identificator (pci address). User then can use nlmon in order to
> be able to use wireshark to see the netlink messages.
> 
> Looks like 2) might be viable, well-defined, generic interface to carry
> this info. What do you think? Does this make sense?

2 seems very interesting, fwiw

  Marcelo

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 08:32:33PM CEST, marcelo.leitner@gmail.com wrote:
>On Wed, Sep 30, 2015 at 03:51:41PM +0200, Jiri Pirko wrote:
>> Hi Dave/all.
>> 
>> There is quite common for drivers to speak with HW using "packet-like"
>> messages. In our case, we put message into skb and push that out as
>> an ordinary packet. HW then sends us reply in a packet, similar to other
>> rx-ed packets.
>
>Better sure than sorry so I'll ask. It's not possible for an application
>to inject such skbs somehow, right?  Like, a guest, tied to a bridge,
>tied to a port which ends up understanding these skbs.

No, it's purely for monitoring of communication with HW.


>
>...
>> 2) generic Netlink (genl) interface. Easy to put metadata in, including the
>> device identificator (pci address). User then can use nlmon in order to
>> be able to use wireshark to see the netlink messages.
>> 
>> Looks like 2) might be viable, well-defined, generic interface to carry
>> this info. What do you think? Does this make sense?
>
>2 seems very interesting, fwiw
>
>  Marcelo

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Mon, Oct 05, 2015 at 05:47:09PM CEST, john.fastabend@gmail.com wrote:
>On 15-10-05 08:35 AM, Jiri Pirko wrote:
>> Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastabend@gmail.com wrote:
>>> On 15-10-05 08:18 AM, Jiri Pirko wrote:
>>>> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>>>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>>>>
>>>>>>> I know nothing about this protocol.....
>>>>>>>
>>>>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>>>>> header and an EtherType which mean EMAD?
>>>>>>
>>>>>> Yep, but that does not really matter. I believe we should find debugging
>>>>>> interface which is protocol agnostic. Just arbitrary messages
>>>>>> monitoring.
>>>>>
>>>>> Hi Jiri
>>>>>
>>>>> O.K, it is just that you mentioned wireshark. Passing the frames to
>>>>> network interface taps would make this trivial.
>>>>
>>>> That is true. But using netlink+nlmon would do the same.
>>>
>>> Also I guess if you go this direction you want to make it generic
>>> enough for any drivers to use it to snoop software/firmware msgs. This
>>> is common across many devices.
>> 
>> Yes, definitelly, this should be something generic to be usable for
>> every device type.
>> 
>> 
>>>
>>> In the past though I've just used ethtool dump commands and some
>>> "scripts" on top of this to debug devices. And when it got really
>>> bad wrote some throw away code to debug my issue. I guess it might
>>> be nice to have something in the kernel to improve this but have
>>> you considered using the tracing features that already exist?
>> 
>> Which ones do you have in mind?
>> 
>
>I was thinking something like kprobes+bpf to dump a trace and
>then a lua script in wireshark to parse the input and pretty
>print it for users. This might get you good-enough support without
>having to carry it around in the kernel just so we can debug
>the devices. We could build some libs/pkgs around it in userspace
>and get it published somewhere so we can all work on it together.

Well, I was thinking rather about some standard interface, not dependent
on actual kernel internals.


>
>I suspect the primary users for this will be developers anyways
>and maybe some users who have a real nasty bug.
>
>> 
>>>
>>> .John
>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>

Re: HW communication debugging interface - ideas?

[John Fastabend]

On 15-10-06 01:14 AM, Jiri Pirko wrote:
> Mon, Oct 05, 2015 at 05:47:09PM CEST, john.fastabend@gmail.com wrote:
>> On 15-10-05 08:35 AM, Jiri Pirko wrote:
>>> Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastabend@gmail.com wrote:
>>>> On 15-10-05 08:18 AM, Jiri Pirko wrote:
>>>>> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>>>>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>>>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>>>>>
>>>>>>>> I know nothing about this protocol.....
>>>>>>>>
>>>>>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>>>>>> header and an EtherType which mean EMAD?
>>>>>>>
>>>>>>> Yep, but that does not really matter. I believe we should find debugging
>>>>>>> interface which is protocol agnostic. Just arbitrary messages
>>>>>>> monitoring.
>>>>>>
>>>>>> Hi Jiri
>>>>>>
>>>>>> O.K, it is just that you mentioned wireshark. Passing the frames to
>>>>>> network interface taps would make this trivial.
>>>>>
>>>>> That is true. But using netlink+nlmon would do the same.
>>>>
>>>> Also I guess if you go this direction you want to make it generic
>>>> enough for any drivers to use it to snoop software/firmware msgs. This
>>>> is common across many devices.
>>>
>>> Yes, definitelly, this should be something generic to be usable for
>>> every device type.
>>>
>>>
>>>>
>>>> In the past though I've just used ethtool dump commands and some
>>>> "scripts" on top of this to debug devices. And when it got really
>>>> bad wrote some throw away code to debug my issue. I guess it might
>>>> be nice to have something in the kernel to improve this but have
>>>> you considered using the tracing features that already exist?
>>>
>>> Which ones do you have in mind?
>>>
>>
>> I was thinking something like kprobes+bpf to dump a trace and
>> then a lua script in wireshark to parse the input and pretty
>> print it for users. This might get you good-enough support without
>> having to carry it around in the kernel just so we can debug
>> the devices. We could build some libs/pkgs around it in userspace
>> and get it published somewhere so we can all work on it together.
> 
> Well, I was thinking rather about some standard interface, not dependent
> on actual kernel internals.
> 


Sure just throwing out an idea. I suspect whatever interface you have
will include the vendor-id or some other identifier and a set of
parsers in user space to pretty print the msg.

.John

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Tue, Oct 06, 2015 at 04:54:09PM CEST, john.fastabend@gmail.com wrote:
>On 15-10-06 01:14 AM, Jiri Pirko wrote:
>> Mon, Oct 05, 2015 at 05:47:09PM CEST, john.fastabend@gmail.com wrote:
>>> On 15-10-05 08:35 AM, Jiri Pirko wrote:
>>>> Mon, Oct 05, 2015 at 05:29:09PM CEST, john.fastabend@gmail.com wrote:
>>>>> On 15-10-05 08:18 AM, Jiri Pirko wrote:
>>>>>> Mon, Oct 05, 2015 at 04:58:42PM CEST, andrew@lunn.ch wrote:
>>>>>>> On Mon, Oct 05, 2015 at 04:55:42PM +0200, Jiri Pirko wrote:
>>>>>>>> Mon, Oct 05, 2015 at 04:49:41PM CEST, andrew@lunn.ch wrote:
>>>>>>>>>>> Are you referring here to messages of the EMAD protocol ?
>>>>>>>>>
>>>>>>>>> I know nothing about this protocol.....
>>>>>>>>>
>>>>>>>>> Does it at least use standard Ethernet framing? Source and Destination
>>>>>>>>> header and an EtherType which mean EMAD?
>>>>>>>>
>>>>>>>> Yep, but that does not really matter. I believe we should find debugging
>>>>>>>> interface which is protocol agnostic. Just arbitrary messages
>>>>>>>> monitoring.
>>>>>>>
>>>>>>> Hi Jiri
>>>>>>>
>>>>>>> O.K, it is just that you mentioned wireshark. Passing the frames to
>>>>>>> network interface taps would make this trivial.
>>>>>>
>>>>>> That is true. But using netlink+nlmon would do the same.
>>>>>
>>>>> Also I guess if you go this direction you want to make it generic
>>>>> enough for any drivers to use it to snoop software/firmware msgs. This
>>>>> is common across many devices.
>>>>
>>>> Yes, definitelly, this should be something generic to be usable for
>>>> every device type.
>>>>
>>>>
>>>>>
>>>>> In the past though I've just used ethtool dump commands and some
>>>>> "scripts" on top of this to debug devices. And when it got really
>>>>> bad wrote some throw away code to debug my issue. I guess it might
>>>>> be nice to have something in the kernel to improve this but have
>>>>> you considered using the tracing features that already exist?
>>>>
>>>> Which ones do you have in mind?
>>>>
>>>
>>> I was thinking something like kprobes+bpf to dump a trace and
>>> then a lua script in wireshark to parse the input and pretty
>>> print it for users. This might get you good-enough support without
>>> having to carry it around in the kernel just so we can debug
>>> the devices. We could build some libs/pkgs around it in userspace
>>> and get it published somewhere so we can all work on it together.
>> 
>> Well, I was thinking rather about some standard interface, not dependent
>> on actual kernel internals.
>> 
>
>
>Sure just throwing out an idea. I suspect whatever interface you have
>will include the vendor-id or some other identifier and a set of
>parsers in user space to pretty print the msg.

Yes, that is the plan.

Re: HW communication debugging interface - ideas?

[Andrew Lunn]

> Sure just throwing out an idea. I suspect whatever interface you have
> will include the vendor-id or some other identifier and a set of
> parsers in user space to pretty print the msg.

If you are going to use wireshark, in this case, all you need to do is
make the stream as being Ethernet frames. The destination and
Ethertype tell you all you need to know to identify the protocol.

	  Andrew

Re: HW communication debugging interface - ideas?

[David Miller]

From: Jiri Pirko <jiri@resnulli.us>
Date: Wed, 30 Sep 2015 15:51:41 +0200

> 2) generic Netlink (genl) interface. Easy to put metadata in, including the
> device identificator (pci address). User then can use nlmon in order to
> be able to use wireshark to see the netlink messages.
> 
> Looks like 2) might be viable, well-defined, generic interface to carry
> this info. What do you think? Does this make sense?

Sorry for the late response.  I definitely prefer this netlink idea,
particularly for the metadata aspect.

Yes, the ethernet frames should "identify" the device, but I much more
like the idea of precisely having the geographic ID of the device (PCI
ID, whatever) available as metadata as well.

Re: HW communication debugging interface - ideas?

[Guy Harris]

On Oct 6, 2015, at 8:02 AM, Andrew Lunn <andrew@lunn.ch> wrote:

>> Sure just throwing out an idea. I suspect whatever interface you have
>> will include the vendor-id or some other identifier and a set of
>> parsers in user space to pretty print the msg.
> 
> If you are going to use wireshark, in this case, all you need to do is
> make the stream as being Ethernet frames. The destination and
> Ethertype tell you all you need to know to identify the protocol.

You will, of course, have registered that Ethertype with the IEEE, to ensure nobody else registers it for use with a different protocol.

Re: HW communication debugging interface - ideas?

[Jiri Pirko]

Sun, Nov 01, 2015 at 05:51:16PM CET, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Wed, 30 Sep 2015 15:51:41 +0200
>
>> 2) generic Netlink (genl) interface. Easy to put metadata in, including the
>> device identificator (pci address). User then can use nlmon in order to
>> be able to use wireshark to see the netlink messages.
>> 
>> Looks like 2) might be viable, well-defined, generic interface to carry
>> this info. What do you think? Does this make sense?
>
>Sorry for the late response.  I definitely prefer this netlink idea,
>particularly for the metadata aspect.
>
>Yes, the ethernet frames should "identify" the device, but I much more
>like the idea of precisely having the geographic ID of the device (PCI
>ID, whatever) available as metadata as well.

Okay. Thanks!