Dear Lincoln, Thank you very much for providing this reference. I've to admit that I didn't know about this library but I'm looking into it but I have some questions/concerns. This library seems to be abandoned since 2 years, at least this is what I see from both the documentation and also their version control system: https://gerrit.o-ran-sc.org/r/gitweb?p=o-du%2Fphy.git;a=summary Do you think it's still reliable? The assumptions seems to be quite restrictive on the HW requirements of this library listed here: https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/Assumptions_Dependencies.html#requirements With my experiments I'm just exploring using virtual interfaces and my HW, I would like to avoid those constraints. From what I can see some of the data structures already provided by DPDK are re-defined by this library, like the eth header data structure and the eCPRI header. I don't know if this is due to implementation reasons or because it has been built with an old version of DPDK. But without taking in consideration the endianess like rte_ecpri.h already does in DPDK and without supporting some msg types (line 94 file xran_pkt.h). Digging into the source code a bit I found some of the data structures I'm referring to in my original message, i.e. the ecpri Seq. ID. The following code puzzles me, source file at: https://gerrit.o-ran-sc.org/r/gitweb?p=o-du/phy.git;a=blob;f=fhi_lib/lib/api/xran_pkt.h;h=314b8d6b7d08f153369de5ad535702f50a574a35;hb=HEAD line 228: struct xran_ecpri_hdr  {      union xran_ecpri_cmn_hdr cmnhdr;      rte_be16_t ecpri_xtc_id;            /**< 3.1.3.1.6 real time control data / IQ data transfer message series identifier */      union ecpri_seq_id ecpri_seq_id;   /**< 3.1.3.1.7 message identifier */  } __rte_packed; Seems strange to me that ecpri_xtc_id is not a data structure on it's own, providing access to DU port, Band Sector etc. Also, the 'xran_pkt_comm_hdr' data structure at line 336 assumes that the packet doesn't have a VLAN header, but, I don't know if this is managed elsewhere. Given all that, I'm still of the idea that could be useful to have those kind of headers directly in DPDK but I'm open to reconsider my statement, please let me know if you have more information regarding this library. Best regards, Mattia On 28/05/2024 16:37, Lincoln Lavoie wrote: > > > You don't often get email from lylavoie@iol.unh.edu. Learn why this is > important > > > > CAUTION:This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > Hi Mattia, > > Have you looked into the O-RAN OSC open fronthaul phy implementation? > https://docs.o-ran-sc.org/projects/o-ran-sc-o-du-phy/en/latest/Architecture-Overview_fh.html > > Cheers, > Lincoln > > On Tue, May 28, 2024 at 10:31 AM Mattia Milani > wrote: > > Dear DPDK Dev community, > > I hope this is the correct mailing list for my questions, otherwise > please excuse me and let me know where my questions should be posted. > > I was looking for a data structure capable to manage O-RAN Fronthaul > CUS-U headers (attached a screenshot of the header structure form a > packet analyzed with Wireshark) > but I couldn't find one. > > I would like to be capable to identify the different port ids but > also > the number of PRBs in the section part. > > I wrote my own implementation for a simple use case (I don't take in > consideration different versions and or data directions) > but it's enough for me at the moment. > > What I wanted to ask is the following: > - Does a data structure for this kind of header already exists? > - If it doesn't exists is it planned? > - If it's not planned could it be of some interest? > > If there is interest I would be happy to share what I developed up to > now to receive comments and/or assistance on how to make it fully > functioning. > > Best regards, > Mattia > > > > -- > *Lincoln Lavoie* > Principal Engineer, Broadband Technologies > 21 Madbury Rd., Ste. 100, Durham, NH 03824 > lylavoie@iol.unh.edu > https://www.iol.unh.edu > +1-603-674-2755 (m) >