Unfortunately I have little experience with RFNOC programming, so perhaps someone else will chime in.
Sent from my iPhone > On Jul 3, 2021, at 5:08 PM, Dario Pennisi <da...@iptronix.com> wrote: > > > Hi Marcus, > I have started looking into this but doesn't seem that straightforward. While > rfnoc provides an easy way to create DSP blocks which interact with each > other, feeding a data stream to a custom streamer endpoint seems a bit > complex. I understand right now it works by injecting chdr packets where > metadata contains IP and port. I need to understand how that works but aside > from this I would also have to resolve Mac addresses via arp. I see the > infrastructure is there but seems quite complex and can't find much > documentation other than source code. > Thanks! > > Dario > > > Il Sab 3 Lug 2021, 20:46 Marcus D Leech <patchvonbr...@gmail.com> ha scritto: >> I will certainly ask R&D about this. >> >> But I wonder if an architecture where you demux inside the FPGA and emit UDP >> packets directly would not be better? Not sure how this would fit within the >> RFNOC framework but since UDP is connectionless, making this work within the >> FPGA should not consume too many resources. >> >> Sent from my iPhone >> >>>> On Jul 3, 2021, at 2:04 PM, Dario Pennisi <da...@iptronix.com> wrote: >>>> >>> >>> I see. Thanks for your help. So the only option would be to make sfp work >>> properly. >>> Can you please check with your colleagues if this is a viable option and >>> what eventually would be needed to make it stable? >>> As I was mentioning if I try to generate sustained traffic the connection >>> is immediately dropped... >>> Thanks >>> >>> Dario >>> >>> Il Sab 3 Lug 2021, 18:51 Marcus D Leech <patchvonbr...@gmail.com> ha >>> scritto: >>>> Looks like jumno frames on the 1Gbit interface are not supported. This is >>>> an underlying Zynq hardware limitation. >>>> >>>> >>>> >>>> Sent from my iPhone >>>> >>>>>> On Jul 3, 2021, at 12:42 PM, Dario Pennisi <da...@iptronix.com> wrote: >>>>>> >>>>> >>>>> Hi, >>>>> data rate is pretty low compared to port capabilities. it's something >>>>> like 1MB/sec per channel. >>>>> in the meantime i did some tests and found the following: >>>>> 1) iperf caps at 88MB/sec if packets are 420 bytes (as i was >>>>> transmitting) with CPU at 50% (single core at 100%) >>>>> 2) iperf caps at 96MB/sec if packets are at least 1000 bytes long >>>>> 3) i tried increasing tx buffers and wmem but that didn't help >>>>> 4) i tried increasing my payload size to 1200 bytes and CPU overhead was >>>>> greatly reduced >>>>> >>>>> from the above it seems to me there's a lot of CPU overhead in sending a >>>>> packet, not really in processing data in the blocks. >>>>> at this point it would be beneficial to increase MTU so that i can reduce >>>>> the number of calls to writev however it seems like eth0 is locked at >>>>> 1500. >>>>> do you have any clue on how to increase that size? >>>>> thanks, >>>>> >>>>> Dario Pennisi >>>>> >>>>>> On Sat, Jul 3, 2021 at 4:53 PM Marcus D Leech <patchvonbr...@gmail.com> >>>>>> wrote: >>>>>> What is the aggregate data rate of all your UDP ports? >>>>>> >>>>>> I’m not sure how “general purpose” the SFP ports are from the >>>>>> perspective of the CPU. They have a special relationship with the FPGA >>>>>> code, but I don’t know the details. >>>>>> >>>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>>> On Jul 3, 2021, at 10:47 AM, Dario Pennisi <da...@iptronix.com> wrote: >>>>>>>> >>>>>>> >>>>>>> Hi Marcus, >>>>>>> thanks for the response. the demux block is in C++ and in the work >>>>>>> function the only things we do are: >>>>>>> - look for EOB tags >>>>>>> - use writev to send a UDP packet with a fixed header prepended to the >>>>>>> data bounded by EOB >>>>>>> >>>>>>> on the other hand the graph is in python but i understand it is only >>>>>>> setting up the endpoint connections and that should not impact >>>>>>> performance. >>>>>>> another issue i see is that apparently eth0 is limited to 1500 MTU and >>>>>>> as i was saying when we tested sending traffic from zynq to SFP port it >>>>>>> didn't really work. >>>>>>> thanks, >>>>>>> >>>>>>> Dario Pennisi >>>>>>> >>>>>>>> On Sat, Jul 3, 2021 at 3:12 PM Marcus D Leech >>>>>>>> <patchvonbr...@gmail.com> wrote: >>>>>>>> If your special demux block is written in Python, that’s the first >>>>>>>> place to look for optimization. A Zynq CPU is only a fraction as >>>>>>>> powerful as even a modest desktop or laptop CPU. So you need to use >>>>>>>> C++ to give it a fighting chance. >>>>>>>> >>>>>>>> Sent from my iPhone >>>>>>>> >>>>>>>>>> On Jul 3, 2021, at 3:39 AM, Dario Pennisi <da...@iptronix.com> wrote: >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> i'm working on a N310 and developed a custom block which processes >>>>>>>>> multiple radio channels generating a low data rate output for each >>>>>>>>> one. i'm outputting this data in a serialized way through a RFNoC >>>>>>>>> block and parsing it through a gnuradio block that demuxes it and >>>>>>>>> sends each channel's data to a socket. this works perfectly if graph >>>>>>>>> runs on a PC but on zynq CPU load rises quickly and with around 20 >>>>>>>>> channels CPU saturates. >>>>>>>>> what demux block work function does is simply looking for EOB tags >>>>>>>>> and sending each chunk of data to an UDP socket using writev, which i >>>>>>>>> hoped was doing zero copy but that doesn't seem to be the case. >>>>>>>>> note that in order for the demux block to work i had to use the 1GB >>>>>>>>> port eth0 as using SFP ports connection would drop right away for >>>>>>>>> some reason. >>>>>>>>> note also i'm using a graph generated in python and haven't yet >>>>>>>>> tested doing the same in C... not sure that would really help anyway. >>>>>>>>> >>>>>>>>> do you have any suggestion to improve UDP packet transmission on >>>>>>>>> zynq, eventually suggesting how to perform real zero copy for UDP >>>>>>>>> traffic in a GNURadio block? >>>>>>>>> >>>>>>>>> thanks! >>>>>>>>> Dario Pennisi >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
