[PATCH] Use time_before in hamradio drivers
From: Marcelo Feitoza Parisi [EMAIL PROTECTED]
Use of time_before() macro, defined at linux/jiffies.h, which deal with
wrapping correctly and are nicer to read.
Signed-off-by: Marcelo Feitoza Parisi [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Signed-off-by: Ralf Baechle DL5RB [EMAIL PROTECTED]
baycom_epp.c |3 ++-
baycom_par.c |3 ++-
baycom_ser_fdx.c |3 ++-
baycom_ser_hdx.c |3 ++-
mkiss.c |3 ++-
5 files changed, 10 insertions(+), 5 deletions(-)
Index: linux-cvs/drivers/net/hamradio/mkiss.c
===
--- linux-cvs.orig/drivers/net/hamradio/mkiss.c 2005-07-15 11:11:26.0
+0100
+++ linux-cvs/drivers/net/hamradio/mkiss.c 2005-07-15 11:12:40.0
+0100
@@ -46,6 +46,7 @@
#include linux/etherdevice.h
#include linux/skbuff.h
#include linux/if_arp.h
+#include linux/jiffies.h
#include net/ax25.h
@@ -429,7 +430,7 @@
* May be we must check transmitter timeout here ?
* 14 Oct 1994 Dmitry Gorodchanin.
*/
- if (jiffies - dev-trans_start 20 * HZ) {
+ if (time_before(jiffies, dev-trans_start + 20 * HZ)) {
/* 20 sec timeout not reached */
return 1;
}
Index: linux-cvs/drivers/net/hamradio/baycom_ser_fdx.c
===
--- linux-cvs.orig/drivers/net/hamradio/baycom_ser_fdx.c2005-07-15
11:11:26.0 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_ser_fdx.c 2005-07-15
11:12:40.0 +0100
@@ -79,6 +79,7 @@
#include asm/io.h
#include linux/hdlcdrv.h
#include linux/baycom.h
+#include linux/jiffies.h
/* - */
@@ -159,7 +160,7 @@
* measure the interrupt frequency
*/
bc-debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc-debug_vals.last_jiffies) = HZ) {
+ if (time_after_eq(cur_jiffies, bc-debug_vals.last_jiffies + HZ)) {
bc-debug_vals.last_jiffies = cur_jiffies;
bc-debug_vals.last_intcnt = bc-debug_vals.cur_intcnt;
bc-debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_ser_hdx.c
===
--- linux-cvs.orig/drivers/net/hamradio/baycom_ser_hdx.c2005-07-15
11:11:26.0 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_ser_hdx.c 2005-07-15
11:12:40.0 +0100
@@ -69,6 +69,7 @@
#include asm/io.h
#include linux/hdlcdrv.h
#include linux/baycom.h
+#include linux/jiffies.h
/* - */
@@ -150,7 +151,7 @@
* measure the interrupt frequency
*/
bc-debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc-debug_vals.last_jiffies) = HZ) {
+ if (time_after_eq(cur_jiffies, bc-debug_vals.last_jiffies + HZ)) {
bc-debug_vals.last_jiffies = cur_jiffies;
bc-debug_vals.last_intcnt = bc-debug_vals.cur_intcnt;
bc-debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_epp.c
===
--- linux-cvs.orig/drivers/net/hamradio/baycom_epp.c2005-07-15
11:11:26.0 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_epp.c 2005-07-15 11:12:40.0
+0100
@@ -54,6 +54,7 @@
#include linux/kmod.h
#include linux/hdlcdrv.h
#include linux/baycom.h
+#include linux/jiffies.h
#if defined(CONFIG_AX25) || defined(CONFIG_AX25_MODULE)
/* prototypes for ax25_encapsulate and ax25_rebuild_header */
#include net/ax25.h
@@ -287,7 +288,7 @@
* measure the interrupt frequency
*/
bc-debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc-debug_vals.last_jiffies) = HZ) {
+ if (time_after_eq(cur_jiffies, bc-debug_vals.last_jiffies + HZ)) {
bc-debug_vals.last_jiffies = cur_jiffies;
bc-debug_vals.last_intcnt = bc-debug_vals.cur_intcnt;
bc-debug_vals.cur_intcnt = 0;
Index: linux-cvs/drivers/net/hamradio/baycom_par.c
===
--- linux-cvs.orig/drivers/net/hamradio/baycom_par.c2005-07-15
11:11:26.0 +0100
+++ linux-cvs/drivers/net/hamradio/baycom_par.c 2005-07-15 11:12:40.0
+0100
@@ -84,6 +84,7 @@
#include linux/baycom.h
#include linux/parport.h
#include linux/bitops.h
+#include linux/jiffies.h
#include asm/bug.h
#include asm/system.h
@@ -165,7 +166,7 @@
* measure the interrupt frequency
*/
bc-debug_vals.cur_intcnt++;
- if ((cur_jiffies - bc-debug_vals.last_jiffies) = HZ) {
+ if (time_after_eq(cur_jiffies, bc-debug_vals.last_jiffies + HZ)) {
bc-debug_vals.last_jiffies = cur_jiffies;
Re: ping behaviour
Andy Furniss [EMAIL PROTECTED] : [...] They will be the same as connexent haven't touched the drivers for years, Patrick ported them to 2.6 and a diff doesn't show any difference involving HZ that I can see. You are comparing two completely different -systems-. Please stop being focused on HZ, ok ? HZ does not rule the priority of the in-kernel tasks. [...] I suppose there could be something in the binary that says if HZ 1000 use it if not use 100 but I could test that - remember running 500 on 2.4 fixed things. From your previous description, it seemed that 2.4 was always fine. Did I miss something ? I still don't know how the driver would know the difference between local and forwarded traffic? You have lost me there. What does local mean ? If it's LAN traffic, the adsl driver has no business with it. [...] That being said, it seems that the 2.6 version of the driver uses workqueues where 2.4 driver used native kernel threads. You can experiment with the priorities there. I'll have to google around that one - but I still secretly hope it's not the driver anyway. Issue a ps command, raise/lower the priority of things like ksoftirqd and see if it makes a difference (on 2.6). -- Ueimor - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ALIGN at crypt/cipher.c
From: Herbert Xu [EMAIL PROTECTED] Date: Fri, 15 Jul 2005 12:27:56 +1000 On Thu, Jul 14, 2005 at 02:36:16PM +, Ken-ichirou MATSUZAWA wrote: No, I think I can understand. align should be unsigned long too. After changing align to unsigned long from int, it works fine. Thanks for pin-pointing the problem Matsuzawa-san. The following patch implements your suggestion to fix the bug where the alignment mask is incorrectly zero-extended on 64-bit architectures. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, thanks Herbert. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/1] drivers/net/pcmcia/smc91c92_cs.c : Use of time_after macro
From: [EMAIL PROTECTED] Date: Thu, 14 Jul 2005 23:41:51 +0200 Use of the time_after() macro, defined at linux/jiffies.h, which deal with wrapping correctly and are nicer to read. Signed-off-by: Marcelo Feitoza Parisi [EMAIL PROTECTED] Signed-off-by: Domen Puncer [EMAIL PROTECTED] Patch applied, thanks. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] fix IP_FIB_HASH kconfig warning
This patch fixes the following kconfig warning: net/ipv4/Kconfig:92:warning: defaults for choice values not supported Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch was already sent on: - 9 Jul 2005 --- linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig.old 2005-07-08 23:55:31.0 +0200 +++ linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig 2005-07-08 23:56:23.0 +0200 @@ -56,9 +56,9 @@ choice prompt Choose IP: FIB lookup algorithm (choose FIB_HASH if unsure) depends on IP_ADVANCED_ROUTER - default IP_FIB_HASH + default ASK_IP_FIB_HASH -config IP_FIB_HASH +config ASK_IP_FIB_HASH bool FIB_HASH ---help--- Current FIB is very proven and good enough for most users. @@ -84,12 +84,8 @@ endchoice -# If the user does not enable advanced routing, he gets the safe -# default of the fib-hash algorithm. config IP_FIB_HASH - bool - depends on !IP_ADVANCED_ROUTER - default y + def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER config IP_MULTIPLE_TABLES bool IP: policy routing - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-copy sniffer.
Jamal, Thanx for forwarding. Somehow I didn't see this one. I guess it's time for me to check my linux-kernel and netdev subscriptions :). Basic idea behind zero-copy is remapping of the physical pages where skb-data lives to the userspace process. According to my tests, which can be found commented in the code (packet_mmap()), remapping of one page gets from 5 upto 20 times faster than copying the same amount of data (i.e. PAGE_SIZE). Interesting. I had exact same idea for TUN/TAP driver. However when I looked at how much stuff needs to be done to remap those pages my first thought was there is no way in hell it can be much much faster than copying. But you are correct that user-kernel copy is slow (relatively speaking) so what I ended up doing was allocating a buffer in the kernel space, mmaping the whole thing once into the user-space and letting user-space app manage it via descriptors (ala Ethernet device ring buffer). Regular memcpy() is used for skb-data to ring copy. I did some measurements of the per packet copy overhead of the current TUN/TAP implementation that uses copy_to_user() vs kernel buffer approach. New code saves about 1000 cycles (P4 M 1.5Ghz) on average. I did not measure it against remapping. Since current VM code requires PTE to be unmapped, when remapping, but only exports unmap_mapping_range() and __flush_tlb(), I used them, although they are quite heavy monsters. It also required mm-mmap_sem to be held, so I placed main remapping code into workqueue. Yeah. I cannot image how this can be more efficient especially on short (100-500 bytes) packets. I guess on large packets you can brake even or even be faster. skbs are queued in prot_hook.func() and then workqueue is being scheduled, where skb is unlinked and remapped. It is not freed there, as it should be, since userspace will never found real data then, but instead some smart algo should be investigated to defer skb freeing, or simple defering using timer and redefined skb destructor. A timer ? What do you set it to ? You just need a descriptor for each packet with status bits (used, unused, etc). It also should remap several skbs at once, so rescheduling would not appeared very frequently. First mapped page is information page, where offset in page of the skb-data is placed, so userspace can detect where actual data lives on the next page. Such schema is very suitable for applications that do not require the whole data flow, but only select some data from the flow, based on packet content. I'm quite sure it will be slower than copying for small packets, I would say not just slower much slower :). Max - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-copy sniffer.
On Fri, Jul 15, 2005 at 03:48:44PM -0700, Max Krasnyansky ([EMAIL PROTECTED]) wrote: Jamal, Thanx for forwarding. Somehow I didn't see this one. I guess it's time for me to check my linux-kernel and netdev subscriptions :). Basic idea behind zero-copy is remapping of the physical pages where skb-data lives to the userspace process. According to my tests, which can be found commented in the code (packet_mmap()), remapping of one page gets from 5 upto 20 times faster than copying the same amount of data (i.e. PAGE_SIZE). Interesting. I had exact same idea for TUN/TAP driver. However when I looked at how much stuff needs to be done to remap those pages my first thought was there is no way in hell it can be much much faster than copying. But you are correct that user-kernel copy is slow (relatively speaking) so what I ended up doing was allocating a buffer in the kernel space, mmaping the whole thing once into the user-space and letting user-space app manage it via descriptors (ala Ethernet device ring buffer). Regular memcpy() is used for skb-data to ring copy. I did some measurements of the per packet copy overhead of the current TUN/TAP implementation that uses copy_to_user() vs kernel buffer approach. New code saves about 1000 cycles (P4 M 1.5Ghz) on average. I did not measure it against remapping. Actually it can be made much faster - it is only needed to replace one TLB entry with another - in current VM code it can be done my remapping appropriate PTE, but code is not exported to the modules, so I used what was exported, which are quite heavy functions. And of course flushing - it can slow things down significantly. Since current VM code requires PTE to be unmapped, when remapping, but only exports unmap_mapping_range() and __flush_tlb(), I used them, although they are quite heavy monsters. It also required mm-mmap_sem to be held, so I placed main remapping code into workqueue. Yeah. I cannot image how this can be more efficient especially on short (100-500 bytes) packets. I guess on large packets you can brake even or even be faster. Sure. It should only be used for at least standard 1500 MTU-sized packets, I can run some tests tomorrow with 1500 buffer size, for smaller packets it is definitely not suitable - here we should have some kind of copying, like in mmaped socket or PF_RING implementation from www.ntop.org and your new tun/tap mechanism. skbs are queued in prot_hook.func() and then workqueue is being scheduled, where skb is unlinked and remapped. It is not freed there, as it should be, since userspace will never found real data then, but instead some smart algo should be investigated to defer skb freeing, or simple defering using timer and redefined skb destructor. A timer ? What do you set it to ? You just need a descriptor for each packet with status bits (used, unused, etc). Current schema is following - according to mmap size I have some budget of packets, i.e. PAGE_SIZE per packet, so if 5 pages were requested to be mapped, so budget is 4, one page is reserved for control block. New skbs are linked into per-socket queue where they are remapped into provided pointers, after remapping skb is queued into list of to be freed skbs. When remapping code will be called next time(i.e. new skb is being received) it checks if some timeout expires after the last freeing, if so, code frees all skbs from the free list except the last budget number of skbs. With high budget userspace will be able to read several times the same skb before budget is exhausted and skbs will be freed. Duplicate reading can be eliminated by checking control block for the same skb cookie of even just offset of skb-data in the page - it is very unlikely in my tests that budget number of skbs will have the same offset of skb-data in the page. It also should remap several skbs at once, so rescheduling would not appeared very frequently. First mapped page is information page, where offset in page of the skb-data is placed, so userspace can detect where actual data lives on the next page. Such schema is very suitable for applications that do not require the whole data flow, but only select some data from the flow, based on packet content. I'm quite sure it will be slower than copying for small packets, I would say not just slower much slower :). I'm not a VM hacker, but it looks like only tlb flushing is the most expensive operation, many other things could be simplified instead of using unmap_mapping_range(). But I agree that for small packets copying is much faster and should be used instead. Max -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-copy sniffer.
Evgeniy, The latest version is available at http://tservice.net.ru/~s0mbre/archive/af_tlb It has several enhancements, fixed some stuff, many cleanups. Fixed/upgraded skb freeing mechanism. Thanks. I'll take a look at it. I think this zero-copy mechanism can be used in tun/tap devices too , although main idea was to implement sniffer module to grab whole traffic as fast as possible - current code requeues skb from prot_hook.func() into per-socket queue, so it could be used for tun/tap device queue too. TUN/TAP has to do pretty much the same thing on RX. ie deliver skbs that show up on tunX interface to the user-space as fast as we can. Max - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Zero-copy sniffer.
On Fri, Jul 15, 2005 at 04:16:17PM -0700, Max Krasnyansky ([EMAIL PROTECTED]) wrote: Evgeniy, The latest version is available at http://tservice.net.ru/~s0mbre/archive/af_tlb It has several enhancements, fixed some stuff, many cleanups. Fixed/upgraded skb freeing mechanism. Thanks. I'll take a look at it. I think this zero-copy mechanism can be used in tun/tap devices too , although main idea was to implement sniffer module to grab whole traffic as fast as possible - current code requeues skb from prot_hook.func() into per-socket queue, so it could be used for tun/tap device queue too. TUN/TAP has to do pretty much the same thing on RX. ie deliver skbs that show up on tunX interface to the user-space as fast as we can. Sure. I think, if remapping idea is worth to be implemented, it could be some common code to be used in TUN/TAP device to receive only specified packets, or packet socket (yet another :) ) to receive all traffic. Max -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] create sysfs device files for hostap
I was writing some scripts to automatically build kismet source lines,
and I noticed that hostap devices don't have device files, unlike my
prism54 and ipw2200 cards:
$ ls -l /sys/class/net/eth0/device
/sys/class/net/eth0/device -
../../../devices/pci:00/:00:1e.0/:02:01.0
$ ls -l /sys/class/net/wifi0
ls: /sys/class/net/wifi0/device: No such file or directory
$ ls -l /sys/class/net/wlan0
ls: /sys/class/net/wlan0/device: No such file or directory
The following (quite small) patch makes sure that both the wlan and wifi
net devices have that pointer to the bus device.
This way, I can do things like
for i in /sys/class/net/*; do
if ! [ -e $i/device/drive ]; then
continue;
fi;
driver=$(basename $(readlink $i/device/driver))
case $driver in
hostap*)
echo -- hostap,$i,$i-$driver
break;
ipw2?00)
echo -- $driver,$i,$i-$driver
break;
prism54)
echo prism54g,$i
esac
done
Which should generate a working set of source lines for kismet no matter
what order I plug the cards in.
It might also be handy to have a link between the two net devices, but
that's a patch for another day.
That patch is against 2.6.13-rc1-mm1.
-- Dave
Signed-off-by: Dave Hansen [EMAIL PROTECTED]
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap.c 2005-07-15
10:57:18.0 -0700
+++ linux-2.6-mm/drivers/net/wireless/hostap/hostap.c 2005-07-15
12:29:15.0 -0700
@@ -141,6 +141,7 @@
if (strchr(dev-name, '%'))
ret = dev_alloc_name(dev, dev-name);
+ SET_NETDEV_DEV(dev, mdev-class_dev.dev);
if (ret = 0)
ret = register_netdevice(dev);
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_cs.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap_cs.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_cs.c 2005-07-15
10:57:18.0 -0700
+++ linux-2.6-mm/drivers/net/wireless/hostap/hostap_cs.c2005-07-15
12:30:57.0 -0700
@@ -739,7 +739,8 @@
}
/* Need to allocate net_device before requesting IRQ handler */
- dev = prism2_init_local_data(prism2_pccard_funcs, 0);
+ dev = prism2_init_local_data(prism2_pccard_funcs, 0,
+handle_to_dev(link-handle));
if (dev == NULL)
goto failed;
link-priv = dev;
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_hw.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap_hw.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_hw.c 2005-07-15
10:57:18.0 -0700
+++ linux-2.6-mm/drivers/net/wireless/hostap/hostap_hw.c2005-07-15
12:27:59.0 -0700
@@ -3268,7 +3268,8 @@
static struct net_device *
-prism2_init_local_data(struct prism2_helper_functions *funcs, int card_idx)
+prism2_init_local_data(struct prism2_helper_functions *funcs, int card_idx,
+ struct device *sdev)
{
struct net_device *dev;
struct hostap_interface *iface;
@@ -3439,6 +3440,7 @@
rtnl_lock();
ret = dev_alloc_name(dev, wifi%d);
+ SET_NETDEV_DEV(dev, sdev);
if (ret = 0)
ret = register_netdevice(dev);
rtnl_unlock();
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_pci.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap_pci.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_pci.c 2005-07-15
10:57:18.0 -0700
+++ linux-2.6-mm/drivers/net/wireless/hostap/hostap_pci.c 2005-07-15
12:17:35.0 -0700
@@ -308,7 +308,8 @@
pci_set_master(pdev);
#endif /* PRISM2_BUS_MASTER */
- dev = prism2_init_local_data(prism2_pci_funcs, cards_found);
+ dev = prism2_init_local_data(prism2_pci_funcs, cards_found,
+pdev-dev);
if (dev == NULL)
goto fail;
iface = netdev_priv(dev);
diff -ru linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_plx.c
linux-2.6-mm/drivers/net/wireless/hostap/hostap_plx.c
--- linux-2.6-mm.orig/drivers/net/wireless/hostap/hostap_plx.c 2005-07-15
10:57:18.0 -0700
+++ linux-2.6-mm/drivers/net/wireless/hostap/hostap_plx.c 2005-07-15
12:17:01.0 -0700
@@ -522,7 +522,8 @@
* not present; but are there really such cards in use(?) */
}
- dev = prism2_init_local_data(prism2_plx_funcs, cards_found);
+ dev = prism2_init_local_data(prism2_plx_funcs, cards_found,
+pdev-dev);
if (dev == NULL)
goto fail;
