From: Mattia Milani <mattia.milani@nokia.com>
To: Lincoln Lavoie <lylavoie@iol.unh.edu>
Cc: dev@dpdk.org
Subject: Re: [Help] O-RAN Fronthaul CUS-U data structure implementation
Date: Mon, 3 Jun 2024 08:36:14 +0200 [thread overview]
Message-ID: <8eda6625-3c98-4a66-b0af-6cb3b2a39dca@nokia.com> (raw)
In-Reply-To: <CAOE1vsMazi_PpnqWV2Z=xaFCPhnhWaT_EogBmKBdeKcAVvNOpg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7100 bytes --]
Hi Lincoln,
Thank you very much for the feedback, I'll look into the documentation
you provided.
In the meanwhile may I ask if there is a publicly available recording of
the training session you mentioned? (or similar training sessions done
in the past).
Thank you,
Mattia
On 31/05/2024 14:40, Lincoln Lavoie wrote:
>
>
> You don't often get email from lylavoie@iol.unh.edu. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
>
>
> 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,
>
> The code is being used, and there are some patches in flight, but are
> currently coming from Open Air Interface folks. There's a lot of
> documentation here:
> https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/develop/doc/ORAN_FHI7.2_Tutorial.md?ref_type=heads
>
> We are actually running this in the lab and even hosted a
> training session on the O-RAN aspects of the setup yesterday with
> Northeastern and the OAI / VIAVI teams. Point is, it's not really
> completely dead, just not a lot of movement in that one repo.
>
> On the hardware, it has been run on both Nvidia and Intel NICs, but
> there are some requirements on things like PTP time stamping, but that
> comes with the O-RAN fronthaul requirements.
>
> For the VLAN header, that is handled with the VFs are creates and
> "handed" to the xran processes that get embedded into the DU (at least
> in the OAI implementation).
>
> Cheers,
> Lincoln
>
>
> On Wed, May 29, 2024 at 4:04 AM Mattia Milani
> <mattia.milani@nokia.com> wrote:
>
> 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
> <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
> <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 <https://aka.ms/LearnAboutSenderIdentification>
>>
>>
>>
>> CAUTION:This is an external email. Please be very careful when
>> clicking links or opening attachments. See the URL nok.it/ext
>> <http://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
>> <mattia.milani@nokia.com> 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)
>> <https://www.iol.unh.edu>
>
>
>
> --
> *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)
> <https://www.iol.unh.edu>
[-- Attachment #2: Type: text/html, Size: 21337 bytes --]
next prev parent reply other threads:[~2024-06-03 6:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-28 14:31 Mattia Milani
2024-05-28 14:37 ` Lincoln Lavoie
2024-05-29 8:04 ` Mattia Milani
2024-05-31 12:40 ` Lincoln Lavoie
2024-06-03 6:36 ` Mattia Milani [this message]
2024-06-03 11:58 ` Lincoln Lavoie
2024-06-04 4:54 ` Mattia Milani (Nokia)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8eda6625-3c98-4a66-b0af-6cb3b2a39dca@nokia.com \
--to=mattia.milani@nokia.com \
--cc=dev@dpdk.org \
--cc=lylavoie@iol.unh.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).