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

Hrishikesh Shelar hshelar at umich.edu
Thu Sep 25 12:55:33 EDT 2014


Ian,

Thanks for your help so far, I think I have got a clear path forward based
on your advice. I am going to use the secondary interface to route my
traffic so I don't interfere with the normal USRP interfacing route. It
seems as though I will not have to make a lot of changes to eth_dispatch; I
see that there is unused logic for routing based on destination ip address.
So I am going to just write the "my ip" address SR accordingly, create an
extra case for routing that traffic to the XO port and maybe hard program
the 'forward_ndest' and 'forward_bcast' bits to be 0. Then I will add a
modified fifo that will drop packets if the downstream (DUC chain) logic is
tied up and only accept packets if there is enough space in the buffer to
ingress an entire packet. The MTU will be set on the host side to not break
this limit. I am not that worried about future proofing the code as it is a
one off deal.

I am going to drop all notions of flow control from my custom DUC to the
host computer and let TCP/IP negotiate the flow. DDC chain isn't
implemented yet but it is the reverse of the DUC (obviously ha).

Thanks again,
Hrishikesh

On Tue, Sep 23, 2014 at 5:22 PM, Ian Buckley <ianb at ionconcepts.com> wrote:

> Hrishikesh,
> 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.
> -Ian
>
> >
> > 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/20140925/8f6b96e0/attachment-0002.html>


More information about the USRP-users mailing list