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

Ian Buckley ianb at ionconcepts.com
Tue Sep 23 20:22:36 EDT 2014

You're diving deep into the USRP internals here so very few folks will be able to help you.
I'm going to assume we are talking about X300 here.

> 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? 

Not with the default programming. Whilst that functionality exists in H/W, the device setup clears the "forward_ndest" and "forward_bcast" bits in the eth_dispatch so that all packets not addressed to the local MAC address are dropped. Likewise broadcast packets are only sent to the ZPU.
If you enable those bits by changing UHD then you are going to have to deal with all manor of unknown and unexpected traffic and make sure it never back pressures up into the eth_dispatch which will very quickly cause the entire USRP to lock up.
> 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 advice to you here is don't try to be to clever with playing games with ARP etc, work within the paradigms of the protocols and the configuration and structures that are already provided largely for free in the USRP. If you really want to parse entire packets yourself in H/W then use a unique UDP socket and make some modest edits to eth_dispatch so that it classifies your packets (white-list rather than wild card) and sends them into your logic. For the time being you could use the XO port if the life time of your project is relatively short term, however if its a long term project then you should plan on future UHD versions enabling and actively using the XO path when the support of X300 daisy chaining is introduced in the future. Thus if you are future proofing then create another egress port from eth_dispatch and add more setting regs in unused address space using the existing code as a blue print. There are unlikely to be RTL changes from upstream to this module at this point as it's stable and complete so you are unlikely to need to do tricky merges in the future. It is very easy to use the ZPU peek/poke interface to program settings registers in this address space and set up your custom logic.

If the volume of your ethernet traffic is low enough then consider just memory mapping your custom logic into the ZPU's buses and using the PEEK/POKE API via UDP…its incredibly simple to use.

> 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.

The simple rule is to NEVER back pressure the ethernet MAC's (1G or 10G), it will immediately interfere with USRP operation, potentially create packet fragments in the pipeline,  and perhaps leave the H/W in a bad state. You must design all your H/W to be able to gracefully sink the maximum possible ethernet packet rate (even if you are just discarding packets to meet this rule). Ettus make no use of PAUSE frames within ethernet and there use will again interfere with normal USRP operation. All Ettus flow control algorithms are implemented above the UDP level in the network stack.

As a general rule when designing for ethernet, expect the worst, indeed the impossible (i.e packets that are illegal by the spec)…traffic will arrive in unexpected bursts even for data streams that have average data rates far lower than the wire speed…whatever your host OS and network H/W, you will be SPAMmed by packets of no interest to you.

> Thanks,
> Hrishikesh
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

More information about the USRP-users mailing list