[USRP-users] Routing IP packets to the straight into the DUC chain

Hrishikesh Shelar hshelar at umich.edu
Tue Sep 23 16:39:11 EDT 2014


Hi Ashish,

Thanks for the help. Unfortunately I am working with full fledged IP
packets as the end-item data format. Although I do not need the ETH frame,
I still need the IP (and in this case TCP/IP) packets to come as is. The
logic accepts an IP packet and puts it on the air using a specific
packetization scheme and modulation.

I looked into packing the IP packets into a VITA format but it would
require custom code on the host computer to pull IP packets of the network
stack and stuff them into VITA packets to route via UHD which I figured may
take too long implement. I think in that case I would even have to create a
separate network stack solely dedicated to sink these IP packets.

Therefore I decided to just use the crossover output of the eth_interface
modules and route that into the DUC blocks. It also seems easiest to just
use the natural route that the IP packets will take (i.e. host computer ->
nic -> ethernet connection). But then in that case there will be a
significant amount of package overflow over the 1 gigE interface which is
why I asked about the PAUSE frame logic. The use of the preexisting flow
control logic with UHD is very appealing but I don't know if I have the
time to setup a virtual network interface on the host computer to grab the
IP packets and pipe them via UHD.

If you still think use of the VITA may be the better option let me know
since I am early enough in the logic writing stage that I could easily make
the switch.

Thanks,
Hrishikesh Shelar

On Tue, Sep 23, 2014 at 12:13 PM, Ashish Chaudhari <
ashish.chaudhari at ettus.com> wrote:

> Hi Hrishikesh,
>
> If I rewired the crossover output from the secondary eth interface
>> straight into my custom logic in the DUC chain then all broadcast and
>> non-USRP destined MAC addresses will get routed into the DUC chain,
>> correct? Say my custom logic then gated the traffic only with MAC addresses
>> equal to X. Then I would manually add some IP address associated with MAC
>> address X, to my host computer ARP table under the interface used to
>> communicate with the secondary eth interface on the USRP. This would
>> effectively create a ghost device that resides within the USRP.
>
>
> Yes, this would theoretically work.
>
> Hence I still use the ZPU to respond to the ARP requests but then I will
>> address the ghost MAC in my application.
>
>
> Be aware that even if the secondary port is not being used, it will
> respond to ARP and ICMP requests based on the IP address and MAC address
> programmed for that port in the flash [1].
>
> So my question is how does the flow control in the simple_gemac_wrapper
>> work?
>
>
> We don't use Ethernet flow control in the X300. We use an end-to-end flow
> control scheme where the endpoints are the host and the radio module in the
> FPGA. With this scheme, it is guaranteed that no data will back up in the
> Eth interface. I won't rely on PAUSE frames working in that logic because
> we have never used or validated it.
>
>
> What kind of data are you planning to send to the DUC chain? If its just
> low speed settings you want to send then I would recommend adding a setting
> register like the one in [2]. If the data is more high-speed and you have
> to use the secondary port then I would recommend tapping the VITA output of
> the eth_dispatch module in eth_interface. The advantage of doing that is
> you don't have to deal with a ghost MAC and IP address because the device
> inherently had both of them. The ZPU will just do that right thing when you
> address the port. Also, the VITA output has the Ethernet, IP and UDP
> headers stripped so all you have to work with is the payload. You do have
> to make sure that the packets that you send from software are proper
> "compressed VITA" packets and that all subsystems in the FPGA are properly
> programmed to route and handle them. Luckily all of that work has been done
> by us in UHD so you can use that code [3]. The format for compressed VITA
> herader (CHDR) is documented here: [4]. [5] is an example of a piece of
> code that formats a cVITA packet in UHD. In terms of flow control you may
> have to validate the pause frame yourself because they just might work or
> implement your own protocol one layer above.
>
> [1] http://files.ettus.com/manual/page_usrp_x3x0.html
> [2]
> https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/top/x300/radio.v#L208
> [3]
> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_impl.cpp#L1109
> [4]
> https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/vita_chdr.txt
> [5]
> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_io_impl.cpp#L179
>
> Hope that helps.
>
> *Ashish Chaudhari* | Senior Software Engineer | High Frequency
> Measurements - RF
> Ettus Research, *A National Instruments Company*
>
> On Wed, Sep 17, 2014 at 1:04 PM, Hrishikesh Shelar via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
>> Hey all,
>>
>> If I rewired the crossover output from the secondary eth interface
>> straight into my custom logic in the DUC chain then all broadcast and
>> non-USRP destined MAC addresses will get routed into the DUC chain,
>> correct?
>>
>> Say my custom logic then gated the traffic only with MAC addresses equal
>> to X. Then I would manually add some IP address associated with MAC address
>> X, to my host computer ARP table under the interface used to communicate
>> with the secondary eth interface on the USRP. This would effectively create
>> a ghost device that resides within the USRP. Hence I still use the ZPU to
>> respond to the ARP requests but then I will address the ghost MAC in my
>> application.
>>
>> So my question is how does the flow control in the simple_gemac_wrapper
>> work? Do you simply enable the logic then assign a value to rx_fifo_space
>> and pause_tresh values? I plan to use this feature to throttle the IP
>> packets that will be fed to the DUC chain.
>>
>> Thanks,
>> Hrishikesh
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140923/e2c26f78/attachment-0002.html>


More information about the USRP-users mailing list