On Thursday, December 16, 2010 10:53:16 pm abcde abcde wrote: > Hi, we ported the nvidia ethernet driver to our product. It's been OK until > recently we ran into an error condition where packets would get dropped > quietly. > The root cause resides in the nfe_encap() routine, where we call nfe_defrag() > to > try to reduce the length of the mbuf chain to 32, if it's longer than 32. In > the > event the 32 mbufs need more than 32 segments, the subsequent call to > bus_dmamap_load_mbuf_sg() would cause it to return an error then the packet > is > subsequently dropped. > > > My questions are, > > 1. there appears to be a generic m_defrag() routine available, which doesn't > stop at 32 and is used by a couple of other drivers (Intel, Broadcom, to name > a > few). What was the need for a nvidia version of the defrag routine?
The nfe_defrag() routine is a copy of a similar method from another driver. It is now called m_collapse() in newer versions of FreeBSD. m_collapse() is less expensive than m_defrag() in that it can avoid extra allocations if they aren't needed. You can use m_defrag() if you wish, but I would still try nfe_defrag() first and only fall back to m_defrag() if that fails. > 2. The NFE_MAX_SCATTER constant, which limits how many segments can be used, > is > defined to be 32, while the corresponding constants for other drivers are 100 > or > 64 (again Intel or Broadcom). How was the value 32 picked? Anybody knows the > reasoning behind them? It may very well be a chip-dependent limitation due to something in the hardware or firmware of the nfe(4) devices. -- John Baldwin _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
