[USRP-users] Routing IP packets to the straight into the DUC chain
ashish.chaudhari at ettus.com
Tue Sep 23 15:13:25 EDT 2014
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 .
So my question is how does the flow control in the simple_gemac_wrapper
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 . 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 . The format for compressed VITA
herader (CHDR) is documented here: .  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.
Hope that helps.
*Ashish Chaudhari* | Senior Software Engineer | High Frequency Measurements
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,
> 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
> 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.
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users