> > > Good luck traveling. I'll update this thread when I figure out more today. >
More details: - My block had a bug which caused CHDR packets to back up so tready coming out of my block and over to the crossbar was being deasserted (note: I don't think this should cause general system mayhem just issues for my block) - The single CTRL port was associated with the backed up endpoint. This means that the garbage CHDR packets were clogging up the pipeline during initialization causing the management packets to get stopped in their tracks and never get to the endpoint. - The eth_ipv4_chdr_dispatch module has a state machine to detect when to drop packets since the 100g can't hold off. Here, the IDLE state goes directly into a DROP state when there is a chdr_push_error (i.e. CHDR downstream is backed up) I think the logic in the eth_ipv4_chdr_dispatch module causes the CPU bound packets (i.e. arp or pings or ssh or whatever) to get dropped once the CHDR pipeline is all backed up, and I think this is undesirable behavior. I see downstream there is the axi4s_packet_gate which will drop the packets that have corrupted contents and the in2 stream gets fanned out to both of the packet gates. I think that first if statement here could be removed: https://github.com/EttusResearch/uhd/blob/master/fpga/usrp3/lib/rfnoc/xport_sv/eth_ipv4_chdr_dispatch.sv#L328 ... since the error conditions are kept around until a tlast is pushed into the packet gate? With that being said, is there a reason why we can't just issue the error flag along with the tlast data coming out and not worry about it in the state machine itself? It looks like in axi_packet_gate that i_terror is only checked with i_tlast anyway, so could this whole thing be simplified a little bit? Just thinking out loud here. Any insights would be appreciated. Thanks, Brian >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
