Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1587960 > unrolled thread

RE: [RFC] Add a parser in fpga_region to decode the tlv meta data suggested by Sundar

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  RE: [RFC] Add a parser in fpga_region to decode the tlv meta data  suggested by Sundar "Nadathur, Sundar" <sundar.nadathur@intel.com> - 2017-02-24 22:50 +0100
    Re: [RFC] Add a parser in fpga_region to decode the tlv meta data  suggested by Sundar Jason Gunthorpe <jgunthorpe@obsidianresearch.com> - 2017-02-24 23:30 +0100

#1587960 — RE: [RFC] Add a parser in fpga_region to decode the tlv meta data suggested by Sundar

On Friday, February 24, 2017 1:17 PM, Jason Gunthorpe wrote:
> Do we need binary data in the header?
> 
> Jason

I have talked about the need for structs and arrays, potentially nested, without really explaining why we may need them eventually. I'll get to that in a moment. But, can we agree that, if nested structs, arrays and general extensibility is needed, FDT or TLVs would be the way to go? If we agree, it becomes a FDT vs. TLV discussion.

Here's why I think we may need extensibility. (Pardon me for starting from the basics -- just trying to set the background.) A FPGA can be programmed as a whole, or can have Partial Reconfiguration (PR) regions, which can be programmed independently. The image programmed into a PR region may have components and sub-units in general. These components may have their own properties. For example, if the FPGA is exposed as a PCIe device to the host, the components may have their own registers in MMIO, DMA attributes and/or interrupts. They may also have identifiers describing their function. In general, we may want these attributes and properties, on  a per-component basis, in the metadata. Even if we don't need them tomorrow, as data center and IOT needs grow, we are likely to need that going forward. 

We could then model the properties of a component as a struct, and the set of components then becomes either an array of structs or a struct of structs. I am not trying to pick a specific object model here-- just mentioning the possibilities. 

IMHO, KVPs are good for scalar quantities. But, when we get to nested arrays/structs, we would need a tree-structured data model, such as TLVs or FDTs. 

Please let me know what you think.

Regards,
Sundar

[toc] | [next] | [standalone]

#1587984

On Fri, Feb 24, 2017 at 09:41:12PM +0000, Nadathur, Sundar wrote:

> I have talked about the need for structs and arrays, potentially
> nested, without really explaining why we may need them
> eventually. I'll get to that in a moment. But, can we agree that, if
> nested structs, arrays and general extensibility is needed, FDT or
> TLVs would be the way to go? If we agree, it becomes a FDT vs. TLV
> discussion.
> 
> Here's why I think we may need extensibility. (Pardon me for
> starting from the basics -- just trying to set the background.) A
> FPGA can be programmed as a whole, or can have Partial
> Reconfiguration (PR) regions, which can be programmed
> independently. The image programmed into a PR region may have
> components and sub-units in general. These components may have their
> own properties. For example, if the FPGA is exposed as a PCIe device
> to the host, the components may have their own registers in MMIO,
> DMA attributes and/or interrupts. They may also have identifiers
> describing their function. In general, we may want these attributes
> and properties, on a per-component basis, in the metadata. Even if
> we don't need them tomorrow, as data center and IOT needs grow, we
> are likely to need that going forward.

So, you are imagining that the FPGA header would include more than
just information relative to programming it, but also something to do
with operating it?

If that is sensible, then I would go with fdt - it is proven to be
able to handle such complex and open-ended needs and has supporting
tooling.

But.. it is crossing over into the DT overlay stuff, if a complex FPGA
like that is a DT overlay + bitfile then we do not need such data in
the bitfile header.

Jason

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web