At 10:23 PM 09/07/2000 +0100, Alan Cox wrote: >> >Your explanation doesn't fit your observations. I suspect #2 may have some >> >significance but that would be unrelated to the rate of resource usage. >> >> Then why does inserting a "mark_bh" after a kfree_skb alleviate the problem >> somewhat? it certainly doesnt add to the performance. > >The mark_bh is already there. it sounds ot me like you are changing timing >patterns by causing a cpu stall on the memory bus > No, its not. I know you are busy, but it would be helpful if you actually read what I wrote before you answer. We have modifyed to ethernet driver to check the address before queuing the packet. There is virtually no overhead. Plus, when packets ARENT freed (such as when they are forwarded) a much more cpu intensive operation of cloning the packet and queuing it is done instead, and there are no problems doing > 100K pps. so its not causing any cpu stalls. Here's a test that even the college freshmen can understand: 1) Set up a box with an eepro100 as a second card and modify the driver by simply replacing netif_rx() with kfree_skb(). My system is a 200Mhz Pentium skb->protocol..... kfree_skb(skb); sp->stats.rx_packets++ yada, yada, yada.... 2) give the card an address with an ifconfig in rc.local 3) wire the box to another box or hub/switch @ 100Mb/s 4) setup a traffic generater on the wire and force the mac address to either broadcast or the mac address of the eepro card ie "arp -s 207.11.14.1 ff:ff:ff:ff:ff:ff" so that the card will get the packets. You can check the rxpacket count with ifconfig to verify that the card is receiving the packets. 5) fire packets at the eepro100 card...my test was about 4000pps. 6) reboot the linux box virtually every time, the eepro driver will complain about "no resources" before the login prompt is displayed. 7) now, modify the driver to include a mark_bh() skb->protocol..... kfree_skb(skb); mark_bh(NET_BH); sp->stats.rx_packets++ yada, yada, yada.... the complaints are noticably less. DB - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
