Not sure if you are still working on this, but it is possible that receive offload could affect/hurt you by causing non-linear skbs.
to see offload settings: ethtool -k eth0 disable receive offload: ethtool -K eth0 gro off lro off it might be worth a shot if it is still easy for you to test. This is a somewhat random guess though. Cliff On Mon, Jan 30, 2012 at 10:21 AM, rchertov <[email protected]> wrote: > > > I wonder if you could print out what nskb->data_len is. It would also > > be great if you had some more time to investigate. Do you know what > > elements you plan to include in the data path? > > I don't think the problem pertains to just the Myricom card. I have an > Intel Oplin dual port card (same chipset as needed for RouteBricks). I > connected both ports with a single loopback cable and ran the following > config on CentOS5.4 running 2.6.24.7 patched kernel. (click was pulled > from git last week commit: f91e115902a1792efca1592a90bb4ac95abaa7e2) > > src1 :: RatedSource(LENGTH 2112, RATE 250000) > -> UDPIPEncap(SRC 10.1.1.4, SPORT 6667, DST 10.1.1.2, DPORT 6667) > -> EtherEncap(0x0800, 00:60:DD:47:94:2A, 00:15:17:7C:E4:A1) > -> ctr1 :: AverageCounter > -> td :: ToDevice(eth2, BURST 16); > > fd :: FromDevice(eth3, PROMISC true, BURST 32) > -> ctr2 :: AverageCounter > -> Discard; > > > Without linearlize (250K pps) > chatter: skb_len: 2112 (I printed this in FromDevice got_skb()) > more /click/ctr2/rate > 250640 > > > With linearlize > chatter: skb_len: 2112 > > more /click/ctr2/rate > 173567 > > > > I don't have a well planned list of elements that I plan to use right > now, but for right now, I am developing a few elements of my own to > support bridging for a high-speed UDP data flow. > > Roman > _______________________________________________ > click mailing list > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
