* Re: [PATCH] TCP congestion module: add TCP-LP supporting for 2.6.16.14
From: David S. Miller @ 2006-05-07 5:48 UTC (permalink / raw)
To: hswong3i; +Cc: netdev, linux-kernel
In-Reply-To: <3feffd230605062232m1b9a3951h6d21071cdacc890f@mail.gmail.com>
How many times are you going to post this same patch over and over
again? Please don't do that, thank you.
We all saw it the first time.
^ permalink raw reply
* [PATCH] TCP congestion module: add TCP-LP supporting for 2.6.16.14
From: Wong Edison @ 2006-05-07 5:32 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
TCP Low Priority is a distributed algorithm whose goal is to utilize only
the excess network bandwidth as compared to the ``fair share`` of
bandwidth as targeted by TCP. Available from:
http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
Original Author:
Aleksandar Kuzmanovic <akuzma@northwestern.edu>
See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
As of 2.6.13, Linux supports pluggable congestion control algorithms.
Due to the limitation of the API, we take the following changes from
the original TCP-LP implementation:
o We use newReno in most core CA handling. Only add some checking
within cong_avoid.
o Error correcting in remote HZ, therefore remote HZ will be keeped
on checking and updating.
o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
OWD have a similar meaning as RTT. Also correct the buggy formular.
o Handle reaction for Early Congestion Indication (ECI) within
pkts_acked, as mentioned within pseudo code.
o OWD is handled in relative format, where local time stamp will in
tcp_time_stamp format.
Port from 2.4.19 to 2.6.16 as module by:
Wong Hoi Sing Edison <hswong3i@gmail.com>
Hung Hing Lun <hlhung3i@gmail.com>
Signed-off-by: Wong Hoi Sing Edison <hswong3i@gmail.com>
---
diff -urpN linux-2.6.16.14/net/ipv4/Kconfig linux/net/ipv4/Kconfig
--- linux-2.6.16.14/net/ipv4/Kconfig 2006-05-05 08:03:45.000000000 +0800
+++ linux/net/ipv4/Kconfig 2006-05-07 01:41:33.000000000 +0800
@@ -531,6 +531,27 @@ config TCP_CONG_SCALABLE
properties, though is known to have fairness issues.
See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
+config TCP_CONG_LP
+ tristate "TCP Low Priority"
+ depends on EXPERIMENTAL
+ default n
+ ---help---
+ TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
+ to utiliza only the excess network bandwidth as compared to the
+ ``fair share`` of bandwidth as targeted by TCP.
+ See http://www-ece.rice.edu/networks/TCP-LP/
+
+config TCP_CONG_LP_DEBUG
+ bool "TCP-LP Debug"
+ depends on TCP_CONG_LP
+ default n
+ ---help---
+ Turn on/off the debug message for TCP-LP. The debug message will
+ print to default kernel debug log file, e.g. /var/log/debug as
+ default. You can use dmesg to obtain the log too.
+
+ If unsure, say N.
+
endmenu
config TCP_CONG_BIC
diff -urpN linux-2.6.16.14/net/ipv4/Makefile linux/net/ipv4/Makefile
--- linux-2.6.16.14/net/ipv4/Makefile 2006-05-05 08:03:45.000000000 +0800
+++ linux/net/ipv4/Makefile 2006-05-07 01:41:33.000000000 +0800
@@ -41,6 +41,7 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybl
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
+obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
xfrm4_output.o
diff -urpN linux-2.6.16.14/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.16.14/net/ipv4/tcp_lp.c 1970-01-01 08:00:00.000000000 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-05-07 01:41:33.000000000 +0800
@@ -0,0 +1,343 @@
+/*
+ * TCP Low Priority (TCP-LP)
+ *
+ * TCP Low Priority is a distributed algorithm whose goal is to utilize only
+ * the excess network bandwidth as compared to the ``fair share`` of
+ * bandwidth as targeted by TCP. Available from:
+ * http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
+ *
+ * Original Author:
+ * Aleksandar Kuzmanovic <akuzma@northwestern.edu>
+ *
+ * See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
+ * As of 2.6.13, Linux supports pluggable congestion control algorithms.
+ * Due to the limitation of the API, we take the following changes from
+ * the original TCP-LP implementation:
+ * o We use newReno in most core CA handling. Only add some checking
+ * within cong_avoid.
+ * o Error correcting in remote HZ, therefore remote HZ will be keeped
+ * on checking and updating.
+ * o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
+ * OWD have a similar meaning as RTT. Also correct the buggy formular.
+ * o Handle reaction for Early Congestion Indication (ECI) within
+ * pkts_acked, as mentioned within pseudo code.
+ * o OWD is handled in relative format, where local time stamp will in
+ * tcp_time_stamp format.
+ *
+ * Port from 2.4.19 to 2.6.16 as module by:
+ * Wong Hoi Sing Edison <hswong3i@gmail.com>
+ * Hung Hing Lun <hlhung3i@gmail.com>
+ *
+ * Version: $Id: tcp_lp.c,v 1.22 2006-05-02 18:18:19 hswong3i Exp $
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <net/tcp.h>
+
+#ifndef CONFIG_TCP_CONG_LP_DEBUG
+#define CONFIG_TCP_CONG_LP_DEBUG 0
+#endif
+
+/* resolution of owd */
+#define LP_RESOL 1000
+
+/**
+ * enum tcp_lp_state
+ * @LP_VALID_RHZ: is remote HZ valid?
+ * @LP_VALID_OWD: is OWD valid?
+ * @LP_WITHIN_THR: are we within threshold?
+ * @LP_WITHIN_INF: are we within inference?
+ *
+ * TCP-LP's state flags.
+ * We create this set of state flag mainly for debugging.
+ */
+enum tcp_lp_state {
+ LP_VALID_RHZ = (1 << 0),
+ LP_VALID_OWD = (1 << 1),
+ LP_WITHIN_THR = (1 << 3),
+ LP_WITHIN_INF = (1 << 4),
+};
+
+/**
+ * struct lp
+ * @flag: TCP-LP state flag
+ * @sowd: smoothed OWD << 3
+ * @owd_min: min OWD
+ * @owd_max: max OWD
+ * @owd_max_rsv: resrved max owd
+ * @remote_hz: estimated remote HZ
+ * @remote_ref_time: remote reference time
+ * @local_ref_time: local reference time
+ * @last_drop: time for last active drop
+ * @inference: current inference
+ *
+ * TCP-LP's private struct.
+ * We get the idea from original TCP-LP implementation where only left those we
+ * found are really useful.
+ */
+struct lp {
+ u32 flag;
+ u32 sowd;
+ u32 owd_min;
+ u32 owd_max;
+ u32 owd_max_rsv;
+ u32 remote_hz;
+ u32 remote_ref_time;
+ u32 local_ref_time;
+ u32 last_drop;
+ u32 inference;
+};
+
+/**
+ * tcp_lp_init
+ *
+ * Init all required variables.
+ * Clone the handling from Vegas module implementation.
+ */
+static void tcp_lp_init(struct sock *sk)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ lp->flag = 0;
+ lp->sowd = 0;
+ lp->owd_min = 0xffffffff;
+ lp->owd_max = 0;
+ lp->owd_max_rsv = 0;
+ lp->remote_hz = 0;
+ lp->remote_ref_time = 0;
+ lp->local_ref_time = 0;
+ lp->last_drop = 0;
+ lp->inference = 0;
+}
+
+/**
+ * tcp_lp_cong_avoid
+ *
+ * Implementation of cong_avoid.
+ * Will only call newReno CA when away from inference.
+ * From TCP-LP's paper, this will be handled in additive increasement.
+ */
+static void tcp_lp_cong_avoid(struct sock *sk, u32 ack, u32 rtt, u32 in_flight,
+ int flag)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ if (!(lp->flag & LP_WITHIN_INF))
+ tcp_reno_cong_avoid(sk, ack, rtt, in_flight, flag);
+}
+
+/**
+ * tcp_lp_remote_hz_estimator
+ *
+ * Estimate remote HZ.
+ * We keep on updating the estimated value, where original TCP-LP
+ * implementation only guest it for once and use forever.
+ */
+static inline u32 tcp_lp_remote_hz_estimator(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+ s64 rhz = lp->remote_hz << 6; /* remote HZ << 6 */
+ s64 m = 0;
+
+ /* not yet record reference time
+ * go away!! record it before come back!! */
+ if (lp->remote_ref_time == 0 || lp->local_ref_time == 0)
+ goto out;
+
+ /* we can't calc remote HZ with no different!! */
+ if (tp->rx_opt.rcv_tsval == lp->remote_ref_time
+ || tp->rx_opt.rcv_tsecr == lp->local_ref_time)
+ goto out;
+
+ m = HZ * (tp->rx_opt.rcv_tsval -
+ lp->remote_ref_time) / (tp->rx_opt.rcv_tsecr -
+ lp->local_ref_time);
+ if (m < 0)
+ m = -m;
+
+ if (rhz != 0) {
+ m -= (rhz >> 6); /* m is now error in remote HZ est */
+ rhz += m; /* 63/64 old + 1/64 new */
+ } else
+ rhz = m << 6;
+
+ /* record time for successful remote HZ calc */
+ lp->flag |= LP_VALID_RHZ;
+
+ out:
+ /* record reference time stamp */
+ lp->remote_ref_time = tp->rx_opt.rcv_tsval;
+ lp->local_ref_time = tp->rx_opt.rcv_tsecr;
+
+ return rhz >> 6;
+}
+
+/**
+ * tcp_lp_owd_calculator
+ *
+ * Calculate one way delay (in relative format).
+ * Original implement OWD as minus of remote time difference to local time
+ * difference directly. As this time difference just simply equal to RTT, when
+ * the network status is stable, remote RTT will equal to local RTT, and result
+ * OWD into zero.
+ * It seems to be a bug and so we fixed it.
+ */
+static inline u32 tcp_lp_owd_calculator(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+ s64 owd = 0;
+
+ lp->remote_hz = tcp_lp_remote_hz_estimator(sk);
+
+ if (lp->flag & LP_VALID_RHZ) {
+ owd =
+ tp->rx_opt.rcv_tsval * (LP_RESOL / lp->remote_hz) -
+ tp->rx_opt.rcv_tsecr * (LP_RESOL / HZ);
+ if (owd < 0)
+ owd = -owd;
+ }
+
+ if (owd > 0)
+ lp->flag |= LP_VALID_OWD;
+ else
+ lp->flag &= ~LP_VALID_OWD;
+
+ return owd;
+}
+
+/**
+ * tcp_lp_rtt_sample
+ *
+ * Implementation or rtt_sample.
+ * Will take the following action,
+ * 1. calc OWD,
+ * 2. record the min/max OWD,
+ * 3. calc smoothed OWD (SOWD).
+ * Most ideas come from the original TCP-LP implementation.
+ */
+static void tcp_lp_rtt_sample(struct sock *sk, u32 usrtt)
+{
+ struct lp *lp = inet_csk_ca(sk);
+ s64 mowd = tcp_lp_owd_calculator(sk);
+
+ /* sorry that we don't have valid data */
+ if (!(lp->flag & LP_VALID_RHZ) || !(lp->flag & LP_VALID_OWD))
+ return;
+
+ /* record the next min owd */
+ if (mowd < lp->owd_min)
+ lp->owd_min = mowd;
+
+ /* always forget the max of the max
+ * we just set owd_max as one below it */
+ if (mowd > lp->owd_max) {
+ if (mowd > lp->owd_max_rsv) {
+ if (lp->owd_max_rsv == 0)
+ lp->owd_max = mowd;
+ else
+ lp->owd_max = lp->owd_max_rsv;
+ lp->owd_max_rsv = mowd;
+ } else
+ lp->owd_max = mowd;
+ }
+
+ /* calc for smoothed owd */
+ if (lp->sowd != 0) {
+ mowd -= (lp->sowd >> 3); /* m is now error in owd est */
+ lp->sowd += mowd; /* owd = 7/8 owd + 1/8 new */
+ } else
+ lp->sowd = mowd << 3; /* take the measured time be owd */
+}
+
+/**
+ * tcp_lp_pkts_acked
+ *
+ * Implementation of pkts_acked.
+ * Deal with active drop under Early Congestion Indication.
+ * Only drop to half and 1 will be handle, because we hope to use back
+ * newReno in increase case.
+ * We work it out by following the idea from TCP-LP's paper directly
+ */
+static void tcp_lp_pkts_acked(struct sock *sk, u32 num_acked)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+
+ /* calc inference */
+ if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
+ lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+
+ /* test if within inference */
+ if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))
+ lp->flag |= LP_WITHIN_INF;
+ else
+ lp->flag &= ~LP_WITHIN_INF;
+
+ /* test if within threshold */
+ if (lp->sowd >> 3 <
+ lp->owd_min + 15 * (lp->owd_max - lp->owd_min) / 100)
+ lp->flag |= LP_WITHIN_THR;
+ else
+ lp->flag &= ~LP_WITHIN_THR;
+
+#if CONFIG_TCP_CONG_LP_DEBUG == 1
+ printk(KERN_DEBUG "TCP-LP: %05o|%5u|%5u|%15u|%15u|%15u\n", lp->flag,
+ tp->snd_cwnd, lp->remote_hz, lp->owd_min, lp->owd_max,
lp->sowd >> 3);
+#endif
+
+ if (lp->flag & LP_WITHIN_THR)
+ return;
+
+ /* FIXME: try to reset owd_min and owd_max here
+ * so decrease the chance the min/max is no longer suitable
+ * and will usually within threshold when whithin inference */
+ lp->owd_min = (lp->sowd >> 3);
+ lp->owd_max = (lp->sowd >> 2);
+ lp->owd_max_rsv = (lp->sowd >> 2);
+
+ /* happened within inference
+ * drop snd_cwnd into 1 */
+ if (lp->flag & LP_WITHIN_INF)
+ tp->snd_cwnd = 1U;
+
+ /* happened after inference
+ * cut snd_cwnd into half */
+ else
+ tp->snd_cwnd = max(tp->snd_cwnd >> 1U, 1U);
+
+ /* record this drop time */
+ lp->last_drop = tcp_time_stamp;
+}
+
+static struct tcp_congestion_ops tcp_lp = {
+ .init = tcp_lp_init,
+ .ssthresh = tcp_reno_ssthresh,
+ .cong_avoid = tcp_lp_cong_avoid,
+ .min_cwnd = tcp_reno_min_cwnd,
+ .rtt_sample = tcp_lp_rtt_sample,
+ .pkts_acked = tcp_lp_pkts_acked,
+
+ .owner = THIS_MODULE,
+ .name = "lp"
+};
+
+static int __init lp_register(void)
+{
+ BUG_ON(sizeof(struct lp) > ICSK_CA_PRIV_SIZE);
+ return tcp_register_congestion_control(&tcp_lp);
+}
+
+static void __exit lp_unregister(void)
+{
+ tcp_unregister_congestion_control(&tcp_lp);
+}
+
+module_init(lp_register);
+module_exit(lp_unregister);
+
+MODULE_AUTHOR("Wong Hoi Sing Edison, Hung Hing Lun");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TCP Low Priority");
^ permalink raw reply
* Re: [rfc][patch] ipvs: use proper timeout instead of fixed value
From: Horms @ 2006-05-07 4:38 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev, wensong, ja
In-Reply-To: <20060505185726.GB24394@gospo.rdu.redhat.com>
On Fri, May 05, 2006 at 02:57:26PM -0400, Andy Gospodarek wrote:
> On Fri, May 05, 2006 at 12:20:54PM +0900, Horms wrote:
> >
> > Sorry, I missunderstood your patch completely the first time around.
> > Yes I think this is an excellent idea. Assuming its tested and works
> > I'm happy to sign off on it and prod DaveM.
>
> Horms,
>
> I'll get a setup together and post results when I have them.
I was thinking that it would be nice if the timeout could be sent over
the wire, though that might bring in some compatibility issues,
and thus your approach might be the best idea.
--
Horms http://www.vergenet.net/~horms/
^ permalink raw reply
* Re: dBm cutoff at -1dBm is too low
From: Pavel Roskin @ 2006-05-07 3:32 UTC (permalink / raw)
To: jt; +Cc: NetDev
In-Reply-To: <20060505172818.GA7543@bougret.hpl.hp.com>
On Fri, 2006-05-05 at 10:28 -0700, Jean Tourrilhes wrote:
> Note that the main limitation is that before I introduced the
> explicit IW_QUAL_DBM in WE-19, the way to know if the value was
> relative or dBm was to use the 'sign' of it, i.e. value above 0 were
> non-dBm. The test is a few line before this snipset :
>
> ---------------------------------------------------------
> /* Check if the statistics are in dBm or relative */
> if((qual->updated & IW_QUAL_DBM)
> || (qual->level > range->max_qual.level))
> {
> ---------------------------------------------------------
>
> There are still quite a few drivers which have not been
> converted to use IW_QUAL_DBM, so I don't want to drop the backward
> compatibility yet.
But shouldn't you trust the drivers using IW_QUAL_DBM, whether the value
is positive or negative?
> Second, the measurement is useful mostly in marginal
> conditions. When signal is great, you don't really care, when signal
> is low, you want to tweak your system to improve reception.
The problem is the driver has to take care of it. It cannot just take
the dBm value from the card and pass it to userspace. It has to limit
the value at -1. Otherwise iwconfig would show -256dBm or something
like that. I can imagine that some GUI can decide that the connection
has become very bad, and that would confuse the user.
> > Wouldn't it be better to put the cutoff at a higher value? The simplest
> > approach would be to treat qual->level and qual->noise as signed char,
> > which would put the cutoff and 127dBm. 500 gigawatts should be enough
> > for everyone :-)
>
> FCC says Tx 1W @ 2.4 GHz, ETSI says Tx 100mW @ 2.4 Gz. Yeah,
> you could use directional antennas. So, realistically, we only need to
> extend to +30dBm.
> On the other hand, I expect that with MIMO and UWB we would
> start to receive signal weaker than what we currently do, and you
> don't want to cutoff the bottom of the range (is -128dBm enough ?).
> I tried to use 'signed' in the struct a long while ago, and
> for some reason it broke left and right, I don't remember the
> details. So, whatever we do, it would not be straightforward.
I suggest -192dBm to 63dBm. That's enough padding on both sides, so
that the drivers can just pass the firmware value without checking.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-07 2:02 UTC (permalink / raw)
To: Jouni Malinen, netdev, Faidon Liambotis, Rick Jones,
Ulrich Kunitz, Harald Welte, Christoph Hellwig
In-Reply-To: <20060506013125.GL27667@instant802.com>
Jouni Malinen wrote:
> On Fri, May 05, 2006 at 03:14:35PM -0500, Larry Finger wrote:
>
> The driver may not know the country code, so there should be mechanism
> for user space to override this.
Do you think an environment variable would suffice, or do you propose another scheme?
>> * Checksum routines will be used to validate the data base. Such a simple
>> scheme will not inhibit anyone with moderate skills from hacking the
>> channel/power settings, but such hacking will require some effort.
>
> I did not see this included in the example file. Did you have more
> detailed plans on how this would be done?
I was anticipating storing the output of an md5sum command in a separate file and comparing the
contents of that file with one computed for the database when the daemon initializes. Is there a
better scheme?
>> * Each channel in the resulting kernel data structure will have appropriate
>> flags set indicating if it is to be used indoors, outdoors, or both. In
>> addition, if the channel should be used only for passive scanning, a
>> suitable flag will be set. In the 2.4 GHz band, a flag will indicate if it
>> should be used for 802.11b, otherwise both b and g mode will be assumed. In
>> the 5.0 GHz bands, a flag will be set if the channel is to conform with
>> 802.11h or 802.11a standards.
>
> 802.11h, radar detection, and DFS may need to be more complex than just
> a one-bit value of it being enabled. Countries may have different
> requirements for different areas related to 802.11h..
I'm afraid that I'm not quite ready for the complexity of 802.11h. Obviously, I need to do more reading.
>> The database consists of two sections. The first relates the Country Codes
>> to a wireless group. The second section describes the channel parameters
>> for the groups. Shown below is a fragment showing the Country Code - Group
>> info for a few countries and the definitions for a few of the groups.
>
> One way to compress this and possible make maintaining quite a bit
> easier would be to use two different set of groups: one for 2.4 GHz band
> and another one for 5 GHz band. Many countries share the same
> requirements for 2.4 GHz, but have different 5 GHz requirements.. This
> is not really a requirement, but could end up making this easier to use.
I don't think it makes too much difference, but I will consider your suggestion as the database
starts to be more complete.
>> Number of Countries: 100
>> Number of Groups: 15
>
> These are not really needed and unless a tool is used to update this
> file, they will most likely end up being out of sync at some point ;-).
> The parser can just read through the file twice if it need to know these
> numbers before parsing (though, that should not really be needed with
> dynamic data structures)..
Your point is well taken. I will remove that data.
>> # group Country Code Description
>> #
>> 1 AT Austria (Standard EU)
>> 1 DE Germany (Standard EU)
>> 2 FRI France Indoor (Not Guyana or La Reunion)
>> 3 FRO France Outdoor (Not Guyana or La Reunion)
>> 4 FR1 French Departments of Guyana and La Reunion Indoor
>> 5 FR2 French Departments of Guyana and La Reunion Outdoor
>
> Country code has to be two characters to fit into country IE..
This problem can be resolved for most of France as long as the driver supplies the country code and
the indoor/outdoor flag. The table would then be:
Group 2 - France (Not Guyana or La Reunion)
#
bg 1 - 8 1 100 B
bg 9 - 13 1 100 I
bg 9 - 13 1 10 O
h 36 - 48 4 200 I
h 52 - 64 4 200 IP
h 100 - 140 4 1000 IP
h 100 - 140 4 1000 OP
The details for the two unique French departments may have to come from the still undetermined
802.11h information.
> AT and DE are a good example of possible use for different 2.4 GHz and 5
> GHz groups.. If I remember correctly, they have the same rules for 2.4
> GHz, but different for 5 GHz.. (unless--of course--they already changed
> them since I looked last time.. ;-)
Yes they have. Following the decision contained in
http://europa.eu.int/eur-lex/lex/LexUriServ/LexUriServ.do?uri=CELEX:32005D0513:EN:NOT, all EU
members and candidates are to adopt the same standards. Most already have. The differences are
outlined in Appendix 3 of the the document downloaded through
http://www.ero.dk/documentation/docs/docfiles.asp?docid=1622&wd=N. Things are changing so fast that
the information for Greece has already changed. The bottom line is that for most EU countries, the
requirements are identical.
>> # Ch. Range - Minimum and Maximum Channels for this range
>> # Ch. Spacing - Number of channels between adjacent entries
>
> Other option would be to use start channel and number of channels.
> Channel spacing is also fixed in practice (1 for 2.4 GHz, 4 for 5 GHz),
> so it may not be needed here.
I decided that if I didn't use the channel spacing, someone would implement a 6 or 8 channel spacing
in the 5 GHz bands.
>> # Power in mW EIRP
>
> I would prefer to see the maximum TX power in dBm, not mW.
This change would have the advantage that the max power in Q5.2 format would fit in the u8 variable
now allocated. I still have to check if any current driver is using this information.
>> # Flag Codes
>> # B - Both Indoor and Outdoor
>> # I - Indoor Only
>> # O - Outdoor Only
>> # P - Passive Scan Only
>
> Some more flags may need to be added in the future. It looks like the
> format used here makes this trivial to extend.
I hope so.
Thanks for your thoughtful comments.
Larry
^ permalink raw reply
* Re: [PATCH] irda-usb: use NULL instead of 0
From: David S. Miller @ 2006-05-07 1:34 UTC (permalink / raw)
To: rdunlap; +Cc: ivdoorn, netdev, jgarzik
In-Reply-To: <20060501153134.811ac2d4.rdunlap@xenotime.net>
From: "Randy.Dunlap" <rdunlap@xenotime.net>
Date: Mon, 1 May 2006 15:31:34 -0700
> Use NULL instead of 0 for a null pointer value (sparse warning):
> drivers/net/irda/irda-usb.c:1781:30: warning: Using plain integer as NULL pointer
>
> Correct timeout argument to use milliseconds instead of jiffies.
>
> Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Applied, thanks Randy.
^ permalink raw reply
* Re: [PATCH] netdev: hotplug napi race cleanup
From: David S. Miller @ 2006-05-07 1:09 UTC (permalink / raw)
To: shemminger; +Cc: herbert, patrakov, netdev, akpm
In-Reply-To: <20060424152341.094b72d8@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 24 Apr 2006 15:23:41 -0700
> This follows after the earlier two patches.
>
> Change the initialization of the class device portion of the net device
> to be done earlier, so that any races before registration completes are
> harmless. Add a mutex to avoid changes to netdevice during the
> class device registration.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
I'm not going to apply this patch and instead request that we think
about why this problem exists in the first place.
This patch is even stronger evidence that doing the sysfs registry in
the todo list processing is wrong. If you can legally do this while
holding the rtnl semaphore, you can just as equally do it inside of
register_netdevice() which is where it truly belongs.
Then you can handle errors properly, unwind the state, and return the
error to the caller instead of just losing the error and leaving the
device in a half-registered state.
^ permalink raw reply
* Re: [RFC] netdev sysfs failure handling
From: David S. Miller @ 2006-05-07 1:06 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20060421134205.2786a0ee@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Fri, 21 Apr 2006 13:42:05 -0700
> In case of sysfs failure, don't let device be brought up.
> It can be cleared by unregister_netdevice so module can be unloaded
> normally.
>
> Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
I'm not so sure about this, a hot plug event could clear that bit too.
The problem I think is that here we've structured things such that we
can't handle the error properly and pass it back to the
register_netdevice() caller because we do the sysfs registry call in
the rtnl_unlock() todo list execution.
Next, even if you prevent the device from being brought up, people
can still assign IP addresses and do other stuff to the device so
it still sort of behaves as if it is there.
It would therefore be the best if we can do this stuff inside of
register_netdevice(), then handle and propagate any errors correctly.
^ permalink raw reply
* Re: IPv6 connect() from site-local to global IPv6 address.
From: David Woodhouse @ 2006-05-06 14:47 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20060506.113904.63157190.yoshfuji@linux-ipv6.org>
On Sat, 2006-05-06 at 11:39 +0900, YOSHIFUJI Hideaki wrote:
> In article <1146876802.2503.32.camel@shinybook.infradead.org> (at Sat, 06 May 2006 01:53:21 +0100), David Woodhouse <dwmw2@infradead.org> says:
>
> > There is a default route, because I believe that's the only thing that
> > radvd can do. I cannot advertise a route to _only_ fec0::/16, can I?
>
> Yes, you can, via Route Information option.
> (>= 2.6.17-rc1 support this.)
Hm. Has radvd also been updated to send it, or did I miss it when I
looked for such an option?
Either way, this isn't particularly useful to me yet, since no deployed
systems support it.
> Anyway, it is valid to use (obsolete) site-local source address
> for global destination address.
> The problem seems that router does NOT send ICMPv6 destination
> unreachable to the sender. I don't know why, but it SHOULD.
I'll pursue that question later. It wouldn't be _sufficient_ since there
are (buggy) programs, including Evolution, which will not fall back to
the second and subsequent addresses from getaddrinfo() -- they'll just
give up when the first attempt to connect fails. So we really do need
the IPv4 address to be listed _first_ in the results, as it used to be.
Glibc _used_ to do what we want -- I always attributed it to Rule 2 of
the destination address selection, without looking hard at the
implementation details.
Let's forget about any details of my current implementation and I'll ask
a _simple_ question...
I have machines on an internal company network, which is all RFC1918
IPv4 addresses and has connectivity by NAT to the outside world. These
machines are mostly Linux, of various versions.
I wish to deploy IPv6 internally so that we can develop and test IPv6
support. There is _no_ chance of getting proper IPv6 connectivity to the
outside world through the corporate firewall. I'd like IPv6 to be usable
_internally_ though, without breaking connectivity to the outside world
over IPv4.
How should I do this?
In the past, I've done it with site-local addresses. A machine on each
Ethernet subnet runs radvd, and machines pick up a site-local address
(and default route) automatically. The machines running radvd also have
IPv6-over-IPv4 tunnels for routing between subnets.
Glibc's getaddrinfo() has in the past given me optimal behaviour. If
connecting to a remote machine which has a site-local IPv6 address, it's
favoured that site-local address. If connecting to a remote machine
which has a _Global_ IPv6 address, it's given the IPv4 address first
instead.
On new kernels, however, glibc has started to return IPv6 addresses even
for external machines which can't be reached. Hence my mail about
$SUBJECT. If I'm doing this the wrong way, what _should_ I be doing?
Uli's response has been to switch glibc so that it _always_ favours IPv4
over IPv6, which AIUI basically means that IPv6 will never get _any_
usage on Linux machines unless in an IPv6-only environment rather than
dual-stack. I.e. Unless I publish _only_ an AAAA record for my server
instead of both A and AAAA records, I won't get any IPv6 traffic. I
think it would be best to avoid that situation.
--
dwmw2
^ permalink raw reply
* Re: IPv6 connect() from site-local to global IPv6 address.
From: David Woodhouse @ 2006-05-06 0:53 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20060506.091920.122414672.yoshfuji@linux-ipv6.org>
On Sat, 2006-05-06 at 09:19 +0900, YOSHIFUJI Hideaki wrote:
> You have compatible address.
> Do you really use the tunnel? How did you configure it?
Sorry, I should have shown a strace from a different machine. Try this
one from an autoconfigured machine...
socket(PF_INET6, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:8b0:10b:1:20d:93ff:fe7a:3f2c", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(32837), inet_pton(AF_INET6, "fec0::1:202:b3ff:fe03:45c1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("81.187.2.168")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(32837), sin_addr=inet_addr("172.16.18.64")}, [16]) = 0
Trying 2001:8b0:10b:1:20d:93ff:fe7a:3f2c...
There is a default route, because I believe that's the only thing that
radvd can do. I cannot advertise a route to _only_ fec0::/16, can I?
(The machine I showed you before was a router between networks --
the ::172.16.18.67 address was on its tunnel interface, and was added
automatically when I created the tunnel and brought it up.)
--
dwmw2
^ permalink raw reply
* Re: [PATCH 2/2] netdev: create attribute_groups with class_device_add
From: David S. Miller @ 2006-05-07 0:21 UTC (permalink / raw)
To: greg; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <20060506225904.GA17704@kroah.com>
From: Greg KH <greg@kroah.com>
Date: Sat, 6 May 2006 15:59:04 -0700
> On Fri, May 05, 2006 at 11:00:50PM -0700, David S. Miller wrote:
> > The networking bit by Stephen is a bug fix.
>
> Good point. Ok, feel free to send both patches to Linus now if you
> want. You can add my:
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> to the driver core change as I have no problems with it.
> Or I can send them on Monday if you wish. Whatever is easier for you.
I'll take care of pushing the changes, thanks Greg.
^ permalink raw reply
* Re: [PATCH 2/2] netdev: create attribute_groups with class_device_add
From: Greg KH @ 2006-05-06 22:59 UTC (permalink / raw)
To: David S. Miller; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <20060505.230050.56609951.davem@davemloft.net>
On Fri, May 05, 2006 at 11:00:50PM -0700, David S. Miller wrote:
> From: Greg KH <greg@kroah.com>
> Date: Fri, 5 May 2006 21:08:39 -0700
>
> > On Fri, May 05, 2006 at 06:41:58PM -0700, David S. Miller wrote:
> > > From: Stephen Hemminger <shemminger@osdl.org>
> > > Date: Fri, 21 Apr 2006 12:54:38 -0700
> > >
> > > > Atomically create attributes when class device is added. This avoids the
> > > > race between registering class_device (which generates hotplug event),
> > > > and the creation of attribute groups.
> > > >
> > > > Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
> > >
> > > Did the first patch that adds the attribute_group creation
> > > infrastructure go in so that we can get this networking fix in?
> >
> > It and the netdev patch are setting in my tree which is showing up in
> > -mm. I'm going to wait until 2.6.17 is out to send the first patch. I
> > can send the second one then too if you want me to (probably make it
> > easier that way.)
>
> The networking bit by Stephen is a bug fix.
Good point. Ok, feel free to send both patches to Linus now if you
want. You can add my:
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
to the driver core change as I have no problems with it.
Or I can send them on Monday if you wish. Whatever is easier for you.
thanks,
greg k-h
^ permalink raw reply
* work with us
From: agroexportlimited1 @ 2006-05-06 21:44 UTC (permalink / raw)
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Larry Finger @ 2006-05-06 19:24 UTC (permalink / raw)
To: Michael Buesch, netdev, Faidon Liambotis, Rick Jones,
Ulrich Kunitz, Harald Welte, Jouni Malinen, Christoph Hellwig
In-Reply-To: <200605062048.46390.mb@bu3sch.de>
Michael Buesch wrote:
> On Friday 05 May 2006 22:14, you wrote:
>> # Groups follow countries
>> #
>> Group 0 - Unspecified Country
>> #
>> # Band Ch. Range Ch. Spacing Power Flags
> ^^^^^^^^^
> Aren't there countries around, where there are gaps in the
> allowed channel numbers? (Especially for 802.11a) So it would
> not be an allowed "range", but an allowed list of channels.
>
Yes, but the gaps are only in 802.11a that I know about. If there is a gap, then I use a second line
as was shown in the example for the standard EU specs. In most cases, other factors change as well.
I initially was going to specify the allowed channels, but the tables got very long. This way is
more compact.
Larry
^ permalink raw reply
* Re: [RFC] Proposed structure for Regulatory/Geographical Wireless database
From: Michael Buesch @ 2006-05-06 18:48 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, Faidon Liambotis, Rick Jones, Ulrich Kunitz, Harald Welte,
Jouni Malinen, Christoph Hellwig
In-Reply-To: <445BB22B.30505@lwfinger.net>
On Friday 05 May 2006 22:14, you wrote:
> # Groups follow countries
> #
> Group 0 - Unspecified Country
> #
> # Band Ch. Range Ch. Spacing Power Flags
^^^^^^^^^
Aren't there countries around, where there are gaps in the
allowed channel numbers? (Especially for 802.11a) So it would
not be an allowed "range", but an allowed list of channels.
--
Greetings Michael.
^ permalink raw reply
* Re: Associate on 'ifconfig up'
From: David Woodhouse @ 2006-05-06 18:24 UTC (permalink / raw)
To: bcm43xx-dev; +Cc: netdev, linville
In-Reply-To: <1146847107.2766.13.camel@pmac.infradead.org>
On Fri, 2006-05-05 at 17:38 +0100, David Woodhouse wrote:
> I still need this hack to work around the fact that softmac doesn't
> attempt to associate when we bring the device up...
It'd be quite good to get this fixed in 2.6.17 too. Otherwise, the
device doesn't manage to associate if you use the fairly common sequence
of iwconfig then dhclient.
It's a bit of an evil hack and it should really be fixed in softmac --
but it's only moving an _existing_ hack from one place in the driver to
another.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c.orig 2006-05-05 17:14:26.000000000 +0100
+++ linux-2.6.16.ppc/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 17:15:19.000000000 +0100
@@ -3263,6 +3263,9 @@ static int bcm43xx_init_board(struct bcm
bcm43xx_sysfs_register(bcm);
//FIXME: check for bcm43xx_sysfs_register failure. This function is a bit messy regarding unwinding, though...
+ /*FIXME: This should be handled by softmac instead. */
+ schedule_work(&bcm->softmac->associnfo.work);
+
assert(err == 0);
out:
return err;
@@ -3937,9 +3940,6 @@ static int bcm43xx_resume(struct pci_dev
netif_device_attach(net_dev);
- /*FIXME: This should be handled by softmac instead. */
- schedule_work(&bcm->softmac->associnfo.work);
-
dprintk(KERN_INFO PFX "Device resumed.\n");
return 0;
--
dwmw2
^ permalink raw reply
* PATCH] TCP congestion module: add TCP-LP supporting for 2.6.16.14
From: Wong Edison @ 2006-05-06 17:55 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
TCP Low Priority is a distributed algorithm whose goal is to utilize only
the excess network bandwidth as compared to the ``fair share`` of
bandwidth as targeted by TCP. Available from:
http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
Original Author:
Aleksandar Kuzmanovic <akuzma@northwestern.edu>
See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
As of 2.6.13, Linux supports pluggable congestion control algorithms.
Due to the limitation of the API, we take the following changes from
the original TCP-LP implementation:
o We use newReno in most core CA handling. Only add some checking
within cong_avoid.
o Error correcting in remote HZ, therefore remote HZ will be keeped
on checking and updating.
o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
OWD have a similar meaning as RTT. Also correct the buggy formular.
o Handle reaction for Early Congestion Indication (ECI) within
pkts_acked, as mentioned within pseudo code.
o OWD is handled in relative format, where local time stamp will in
tcp_time_stamp format.
Port from 2.4.19 to 2.6.16 as module by:
Wong Hoi Sing Edison <hswong3i@gmail.com>
Hung Hing Lun <hlhung3i@gmail.com>
Signed-off-by: Wong Hoi Sing Edison <hswong3i@gmail.com>
---
diff -urpN linux-2.6.16.14/net/ipv4/Kconfig linux/net/ipv4/Kconfig
--- linux-2.6.16.14/net/ipv4/Kconfig 2006-05-05 08:03:45.000000000 +0800
+++ linux/net/ipv4/Kconfig 2006-05-07 01:41:33.000000000 +0800
@@ -531,6 +531,27 @@ config TCP_CONG_SCALABLE
properties, though is known to have fairness issues.
See http://www-lce.eng.cam.ac.uk/~ctk21/scalable/
+config TCP_CONG_LP
+ tristate "TCP Low Priority"
+ depends on EXPERIMENTAL
+ default n
+ ---help---
+ TCP Low Priority (TCP-LP), a distributed algorithm whose goal is
+ to utiliza only the excess network bandwidth as compared to the
+ ``fair share`` of bandwidth as targeted by TCP.
+ See http://www-ece.rice.edu/networks/TCP-LP/
+
+config TCP_CONG_LP_DEBUG
+ bool "TCP-LP Debug"
+ depends on TCP_CONG_LP
+ default n
+ ---help---
+ Turn on/off the debug message for TCP-LP. The debug message will
+ print to default kernel debug log file, e.g. /var/log/debug as
+ default. You can use dmesg to obtain the log too.
+
+ If unsure, say N.
+
endmenu
config TCP_CONG_BIC
diff -urpN linux-2.6.16.14/net/ipv4/Makefile linux/net/ipv4/Makefile
--- linux-2.6.16.14/net/ipv4/Makefile 2006-05-05 08:03:45.000000000 +0800
+++ linux/net/ipv4/Makefile 2006-05-07 01:41:33.000000000 +0800
@@ -41,6 +41,7 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybl
obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
+obj-$(CONFIG_TCP_CONG_LP) += tcp_lp.o
obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
xfrm4_output.o
diff -urpN linux-2.6.16.14/net/ipv4/tcp_lp.c linux/net/ipv4/tcp_lp.c
--- linux-2.6.16.14/net/ipv4/tcp_lp.c 1970-01-01 08:00:00.000000000 +0800
+++ linux/net/ipv4/tcp_lp.c 2006-05-07 01:41:33.000000000 +0800
@@ -0,0 +1,343 @@
+/*
+ * TCP Low Priority (TCP-LP)
+ *
+ * TCP Low Priority is a distributed algorithm whose goal is to utilize only
+ * the excess network bandwidth as compared to the ``fair share`` of
+ * bandwidth as targeted by TCP. Available from:
+ * http://www.ece.rice.edu/~akuzma/Doc/akuzma/TCP-LP.pdf
+ *
+ * Original Author:
+ * Aleksandar Kuzmanovic <akuzma@northwestern.edu>
+ *
+ * See http://www-ece.rice.edu/networks/TCP-LP/ for their implementation.
+ * As of 2.6.13, Linux supports pluggable congestion control algorithms.
+ * Due to the limitation of the API, we take the following changes from
+ * the original TCP-LP implementation:
+ * o We use newReno in most core CA handling. Only add some checking
+ * within cong_avoid.
+ * o Error correcting in remote HZ, therefore remote HZ will be keeped
+ * on checking and updating.
+ * o Handling calculation of One-Way-Delay (OWD) within rtt_sample, sicne
+ * OWD have a similar meaning as RTT. Also correct the buggy formular.
+ * o Handle reaction for Early Congestion Indication (ECI) within
+ * pkts_acked, as mentioned within pseudo code.
+ * o OWD is handled in relative format, where local time stamp will in
+ * tcp_time_stamp format.
+ *
+ * Port from 2.4.19 to 2.6.16 as module by:
+ * Wong Hoi Sing Edison <hswong3i@gmail.com>
+ * Hung Hing Lun <hlhung3i@gmail.com>
+ *
+ * Version: $Id: tcp_lp.c,v 1.22 2006-05-02 18:18:19 hswong3i Exp $
+ */
+
+#include <linux/config.h>
+#include <linux/module.h>
+#include <net/tcp.h>
+
+#ifndef CONFIG_TCP_CONG_LP_DEBUG
+#define CONFIG_TCP_CONG_LP_DEBUG 0
+#endif
+
+/* resolution of owd */
+#define LP_RESOL 1000
+
+/**
+ * enum tcp_lp_state
+ * @LP_VALID_RHZ: is remote HZ valid?
+ * @LP_VALID_OWD: is OWD valid?
+ * @LP_WITHIN_THR: are we within threshold?
+ * @LP_WITHIN_INF: are we within inference?
+ *
+ * TCP-LP's state flags.
+ * We create this set of state flag mainly for debugging.
+ */
+enum tcp_lp_state {
+ LP_VALID_RHZ = (1 << 0),
+ LP_VALID_OWD = (1 << 1),
+ LP_WITHIN_THR = (1 << 3),
+ LP_WITHIN_INF = (1 << 4),
+};
+
+/**
+ * struct lp
+ * @flag: TCP-LP state flag
+ * @sowd: smoothed OWD << 3
+ * @owd_min: min OWD
+ * @owd_max: max OWD
+ * @owd_max_rsv: resrved max owd
+ * @remote_hz: estimated remote HZ
+ * @remote_ref_time: remote reference time
+ * @local_ref_time: local reference time
+ * @last_drop: time for last active drop
+ * @inference: current inference
+ *
+ * TCP-LP's private struct.
+ * We get the idea from original TCP-LP implementation where only left those we
+ * found are really useful.
+ */
+struct lp {
+ u32 flag;
+ u32 sowd;
+ u32 owd_min;
+ u32 owd_max;
+ u32 owd_max_rsv;
+ u32 remote_hz;
+ u32 remote_ref_time;
+ u32 local_ref_time;
+ u32 last_drop;
+ u32 inference;
+};
+
+/**
+ * tcp_lp_init
+ *
+ * Init all required variables.
+ * Clone the handling from Vegas module implementation.
+ */
+static void tcp_lp_init(struct sock *sk)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ lp->flag = 0;
+ lp->sowd = 0;
+ lp->owd_min = 0xffffffff;
+ lp->owd_max = 0;
+ lp->owd_max_rsv = 0;
+ lp->remote_hz = 0;
+ lp->remote_ref_time = 0;
+ lp->local_ref_time = 0;
+ lp->last_drop = 0;
+ lp->inference = 0;
+}
+
+/**
+ * tcp_lp_cong_avoid
+ *
+ * Implementation of cong_avoid.
+ * Will only call newReno CA when away from inference.
+ * From TCP-LP's paper, this will be handled in additive increasement.
+ */
+static void tcp_lp_cong_avoid(struct sock *sk, u32 ack, u32 rtt, u32 in_flight,
+ int flag)
+{
+ struct lp *lp = inet_csk_ca(sk);
+
+ if (!(lp->flag & LP_WITHIN_INF))
+ tcp_reno_cong_avoid(sk, ack, rtt, in_flight, flag);
+}
+
+/**
+ * tcp_lp_remote_hz_estimator
+ *
+ * Estimate remote HZ.
+ * We keep on updating the estimated value, where original TCP-LP
+ * implementation only guest it for once and use forever.
+ */
+static inline u32 tcp_lp_remote_hz_estimator(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+ s64 rhz = lp->remote_hz << 6; /* remote HZ << 6 */
+ s64 m = 0;
+
+ /* not yet record reference time
+ * go away!! record it before come back!! */
+ if (lp->remote_ref_time == 0 || lp->local_ref_time == 0)
+ goto out;
+
+ /* we can't calc remote HZ with no different!! */
+ if (tp->rx_opt.rcv_tsval == lp->remote_ref_time
+ || tp->rx_opt.rcv_tsecr == lp->local_ref_time)
+ goto out;
+
+ m = HZ * (tp->rx_opt.rcv_tsval -
+ lp->remote_ref_time) / (tp->rx_opt.rcv_tsecr -
+ lp->local_ref_time);
+ if (m < 0)
+ m = -m;
+
+ if (rhz != 0) {
+ m -= (rhz >> 6); /* m is now error in remote HZ est */
+ rhz += m; /* 63/64 old + 1/64 new */
+ } else
+ rhz = m << 6;
+
+ /* record time for successful remote HZ calc */
+ lp->flag |= LP_VALID_RHZ;
+
+ out:
+ /* record reference time stamp */
+ lp->remote_ref_time = tp->rx_opt.rcv_tsval;
+ lp->local_ref_time = tp->rx_opt.rcv_tsecr;
+
+ return rhz >> 6;
+}
+
+/**
+ * tcp_lp_owd_calculator
+ *
+ * Calculate one way delay (in relative format).
+ * Original implement OWD as minus of remote time difference to local time
+ * difference directly. As this time difference just simply equal to RTT, when
+ * the network status is stable, remote RTT will equal to local RTT, and result
+ * OWD into zero.
+ * It seems to be a bug and so we fixed it.
+ */
+static inline u32 tcp_lp_owd_calculator(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+ s64 owd = 0;
+
+ lp->remote_hz = tcp_lp_remote_hz_estimator(sk);
+
+ if (lp->flag & LP_VALID_RHZ) {
+ owd =
+ tp->rx_opt.rcv_tsval * (LP_RESOL / lp->remote_hz) -
+ tp->rx_opt.rcv_tsecr * (LP_RESOL / HZ);
+ if (owd < 0)
+ owd = -owd;
+ }
+
+ if (owd > 0)
+ lp->flag |= LP_VALID_OWD;
+ else
+ lp->flag &= ~LP_VALID_OWD;
+
+ return owd;
+}
+
+/**
+ * tcp_lp_rtt_sample
+ *
+ * Implementation or rtt_sample.
+ * Will take the following action,
+ * 1. calc OWD,
+ * 2. record the min/max OWD,
+ * 3. calc smoothed OWD (SOWD).
+ * Most ideas come from the original TCP-LP implementation.
+ */
+static void tcp_lp_rtt_sample(struct sock *sk, u32 usrtt)
+{
+ struct lp *lp = inet_csk_ca(sk);
+ s64 mowd = tcp_lp_owd_calculator(sk);
+
+ /* sorry that we don't have valid data */
+ if (!(lp->flag & LP_VALID_RHZ) || !(lp->flag & LP_VALID_OWD))
+ return;
+
+ /* record the next min owd */
+ if (mowd < lp->owd_min)
+ lp->owd_min = mowd;
+
+ /* always forget the max of the max
+ * we just set owd_max as one below it */
+ if (mowd > lp->owd_max) {
+ if (mowd > lp->owd_max_rsv) {
+ if (lp->owd_max_rsv == 0)
+ lp->owd_max = mowd;
+ else
+ lp->owd_max = lp->owd_max_rsv;
+ lp->owd_max_rsv = mowd;
+ } else
+ lp->owd_max = mowd;
+ }
+
+ /* calc for smoothed owd */
+ if (lp->sowd != 0) {
+ mowd -= (lp->sowd >> 3); /* m is now error in owd est */
+ lp->sowd += mowd; /* owd = 7/8 owd + 1/8 new */
+ } else
+ lp->sowd = mowd << 3; /* take the measured time be owd */
+}
+
+/**
+ * tcp_lp_pkts_acked
+ *
+ * Implementation of pkts_acked.
+ * Deal with active drop under Early Congestion Indication.
+ * Only drop to half and 1 will be handle, because we hope to use back
+ * newReno in increase case.
+ * We work it out by following the idea from TCP-LP's paper directly
+ */
+static void tcp_lp_pkts_acked(struct sock *sk, u32 num_acked)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct lp *lp = inet_csk_ca(sk);
+
+ /* calc inference */
+ if (tcp_time_stamp > tp->rx_opt.rcv_tsecr)
+ lp->inference = 3 * (tcp_time_stamp - tp->rx_opt.rcv_tsecr);
+
+ /* test if within inference */
+ if (lp->last_drop && (tcp_time_stamp - lp->last_drop < lp->inference))
+ lp->flag |= LP_WITHIN_INF;
+ else
+ lp->flag &= ~LP_WITHIN_INF;
+
+ /* test if within threshold */
+ if (lp->sowd >> 3 <
+ lp->owd_min + 15 * (lp->owd_max - lp->owd_min) / 100)
+ lp->flag |= LP_WITHIN_THR;
+ else
+ lp->flag &= ~LP_WITHIN_THR;
+
+#if CONFIG_TCP_CONG_LP_DEBUG == 1
+ printk(KERN_DEBUG "TCP-LP: %05o|%5u|%5u|%15u|%15u|%15u\n", lp->flag,
+ tp->snd_cwnd, lp->remote_hz, lp->owd_min, lp->owd_max, lp->sowd >> 3);
+#endif
+
+ if (lp->flag & LP_WITHIN_THR)
+ return;
+
+ /* FIXME: try to reset owd_min and owd_max here
+ * so decrease the chance the min/max is no longer suitable
+ * and will usually within threshold when whithin inference */
+ lp->owd_min = (lp->sowd >> 3);
+ lp->owd_max = (lp->sowd >> 2);
+ lp->owd_max_rsv = (lp->sowd >> 2);
+
+ /* happened within inference
+ * drop snd_cwnd into 1 */
+ if (lp->flag & LP_WITHIN_INF)
+ tp->snd_cwnd = 1U;
+
+ /* happened after inference
+ * cut snd_cwnd into half */
+ else
+ tp->snd_cwnd = max(tp->snd_cwnd >> 1U, 1U);
+
+ /* record this drop time */
+ lp->last_drop = tcp_time_stamp;
+}
+
+static struct tcp_congestion_ops tcp_lp = {
+ .init = tcp_lp_init,
+ .ssthresh = tcp_reno_ssthresh,
+ .cong_avoid = tcp_lp_cong_avoid,
+ .min_cwnd = tcp_reno_min_cwnd,
+ .rtt_sample = tcp_lp_rtt_sample,
+ .pkts_acked = tcp_lp_pkts_acked,
+
+ .owner = THIS_MODULE,
+ .name = "lp"
+};
+
+static int __init lp_register(void)
+{
+ BUG_ON(sizeof(struct lp) > ICSK_CA_PRIV_SIZE);
+ return tcp_register_congestion_control(&tcp_lp);
+}
+
+static void __exit lp_unregister(void)
+{
+ tcp_unregister_congestion_control(&tcp_lp);
+}
+
+module_init(lp_register);
+module_exit(lp_unregister);
+
+MODULE_AUTHOR("Wong Hoi Sing Edison, Hung Hing Lun");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("TCP Low Priority");
^ permalink raw reply
* Re: [PATCH 2/3] bcm43xx-d80211: fix whitespace
From: Michael Buesch @ 2006-05-06 17:43 UTC (permalink / raw)
To: Stefano Brivio; +Cc: bcm43xx-dev, netdev, John W. Linville
In-Reply-To: <20060505215959.35be978d@localhost>
On Friday 05 May 2006 21:59, Stefano Brivio wrote:
> Fix whitespace.
>
> Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
>
> Index: wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c
> ===================================================================
> --- wireless-dev.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 00:50:00.370034536 +0200
> +++ wireless-dev/drivers/net/wireless/bcm43xx/bcm43xx_main.c 2006-05-05 02:43:44.981535888 +0200
All your d80211 patches are _not_ against the dscape port
of the bcm43xx driver. The dscape port is located at:
wireless-dev/drivers/net/wireless/d80211/bcm43xx/
> @@ -128,13 +128,13 @@
> static struct pci_device_id bcm43xx_pci_tbl[] = {
> /* Broadcom 4303 802.11b */
> { PCI_VENDOR_ID_BROADCOM, 0x4301, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> - /* Broadcom 4307 802.11b */
> + /* Broadcom 4307 802.11b */
> { PCI_VENDOR_ID_BROADCOM, 0x4307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> - /* Broadcom 4318 802.11b/g */
> + /* Broadcom 4318 802.11b/g */
> { PCI_VENDOR_ID_BROADCOM, 0x4318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> /* Broadcom 4306 802.11b/g */
> { PCI_VENDOR_ID_BROADCOM, 0x4320, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> - /* Broadcom 4306 802.11a */
> + /* Broadcom 4306 802.11a */
> // { PCI_VENDOR_ID_BROADCOM, 0x4321, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
> /* Broadcom 4309 802.11a/b/g */
> { PCI_VENDOR_ID_BROADCOM, 0x4324, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
>
>
> --
> Ciao
> Stefano
> _______________________________________________
> Bcm43xx-dev mailing list
> Bcm43xx-dev@lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>
--
Greetings Michael.
^ permalink raw reply
* Re: Fw: [Bugme-new] [Bug 6495] New: Vlan MTU Fragmentation
From: Ben Greear @ 2006-05-06 17:20 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, slavon
In-Reply-To: <20060505231759.5ad77e95.akpm@osdl.org>
Andrew Morton wrote:
> I guess I can type simple commands and add printks. Do you have time to
> take a look at the driver and suggest what I should be looking for?
I can only offer vague hints:
TX usually works, but RX often has isues. There is usually a bit
or two that needs setting to enable the larger than MTU pkt RX.
It seems some older chipsets had issues with doing checksum offload
for VLAN packets, so could try disabling the UDP/TCP checksum logic
and see if that helps.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] fix IP-over-ATM and ARP interaction - formatting fixed.
From: Simon Kelley @ 2006-05-06 17:02 UTC (permalink / raw)
To: davem, netdev
The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
ARP table, using the standard neighbour-table code. The
neigh_table_init function adds this neighbour table to a linked
list of all neighbor tables which is used by the functions
neigh_delete() neigh_add() and neightbl_set(), all called by
the netlink code.
Once the ATM neighbour table is added to the list, there are two tables
with family == AF_INET there, and ARP entries sent via netlink go into
the first table with matching family. This is indeterminate and often wrong.
To see the bug, on a kernel with CLIP enabled, create a standard IPv4
ARP entry by pinging an unused address on a local subnet. Then attempt
to complete that entry by doing
ip neigh replace <ip address> lladdr <some mac address> nud reachable
Looking at the ARP tables by using
ip neigh show
will reveal two ARP entries for the same address. One of these can be
found in /proc/net/arp, and the other in /proc/net/atm/arp.
This patch adds a new function, neigh_table_init_no_netlink() which
does everything the neigh_table_init() does, except add the table to
the netlink all-arp-tables chain. In addition neigh_table_init() has a
check that all tables on the chain have a distinct address family.
The init call in clip.c is changed to call neigh_table_init_no_netlink().
Since ATM ARP tables are rather more complicated than can currently be
handled by the available rtattrs in the netlink protocol, no
functionality is lost by this patch, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr for
ATM ARP entries and some way for the netlink code to give neigh_add
and friends more information than just address family with which to find
the correct ARP table.
Signed-off-by: Simon Kelley <simon@thekelleys.org.uk>
--
diff -Naur linux-2.6.16.11.orig/include/net/neighbour.h linux-2.6.16.11/include/net/neighbour.h
--- linux-2.6.16.11.orig/include/net/neighbour.h 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/include/net/neighbour.h 2006-05-04 20:09:17.000000000 +0100
@@ -211,6 +211,7 @@
#define NEIGH_UPDATE_F_ADMIN 0x80000000
extern void neigh_table_init(struct neigh_table *tbl);
+extern void neigh_table_init_no_netlink(struct neigh_table *tbl);
extern int neigh_table_clear(struct neigh_table *tbl);
extern struct neighbour * neigh_lookup(struct neigh_table *tbl,
const void *pkey,
diff -Naur linux-2.6.16.11.orig/net/atm/clip.c linux-2.6.16.11/net/atm/clip.c
--- linux-2.6.16.11.orig/net/atm/clip.c 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/net/atm/clip.c 2006-05-04 20:10:00.000000000 +0100
@@ -995,7 +995,7 @@
static int __init atm_clip_init(void)
{
- neigh_table_init(&clip_tbl);
+ neigh_table_init_no_netlink(&clip_tbl);
clip_tbl_hook = &clip_tbl;
register_atm_ioctl(&clip_ioctl_ops);
diff -Naur linux-2.6.16.11.orig/net/core/neighbour.c linux-2.6.16.11/net/core/neighbour.c
--- linux-2.6.16.11.orig/net/core/neighbour.c 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/net/core/neighbour.c 2006-05-06 17:44:30.000000000 +0100
@@ -1322,8 +1322,7 @@
kfree(parms);
}
-
-void neigh_table_init(struct neigh_table *tbl)
+void neigh_table_init_no_netlink(struct neigh_table *tbl)
{
unsigned long now = jiffies;
unsigned long phsize;
@@ -1381,7 +1380,16 @@
tbl->last_flush = now;
tbl->last_rand = now + tbl->parms.reachable_time * 20;
+}
+
+void neigh_table_init(struct neigh_table *tbl)
+{
+ struct neigh_table *tmp;
+
+ neigh_table_init_no_netlink(tbl);
write_lock(&neigh_tbl_lock);
+ for (tmp = neigh_tables; tmp; tmp = tmp->next)
+ BUG_ON(tmp->family == tbl->family);
tbl->next = neigh_tables;
neigh_tables = tbl;
write_unlock(&neigh_tbl_lock);
@@ -2655,6 +2663,7 @@
EXPORT_SYMBOL(neigh_resolve_output);
EXPORT_SYMBOL(neigh_table_clear);
EXPORT_SYMBOL(neigh_table_init);
+EXPORT_SYMBOL(neigh_table_init_no_netlink);
EXPORT_SYMBOL(neigh_update);
EXPORT_SYMBOL(neigh_update_hhs);
EXPORT_SYMBOL(pneigh_enqueue);
^ permalink raw reply
* Re: [PATCH] fix IP-over-ATM and ARP interaction.
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2006-05-06 16:31 UTC (permalink / raw)
To: simon; +Cc: davem, netdev, yoshfuji
In-Reply-To: <E1FcPPN-0004xi-00@thekelleys.org.uk>
In article <E1FcPPN-0004xi-00@thekelleys.org.uk> (at Sat, 06 May 2006 17:13:29 +0100), Simon Kelley <simon@thekelleys.org.uk> says:
> +void neigh_table_init(struct neigh_table *tbl)
> +{
> + struct neigh_table *tmp;
> +
> + neigh_table_init_no_netlink(tbl);
> + write_lock(&neigh_tbl_lock);
> + for (tmp = neigh_tables; tmp; tmp = tmp->next)
> + BUG_ON(tmp->family == tbl->family);
> + tbl->next = neigh_tables;
> + neigh_tables = tbl;
> + write_unlock(&neigh_tbl_lock);
> }
>
> int neigh_table_clear(struct neigh_table *tbl)
Please fix the coding style; use tab for indent, please.
--yoshfuji
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6502] New: SIOCSIFHWBROADCAST needs compat layer
From: Andrew Morton @ 2006-05-06 16:27 UTC (permalink / raw)
To: netdev; +Cc: bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Sat, 6 May 2006 08:24:25 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6502] New: SIOCSIFHWBROADCAST needs compat layer
http://bugzilla.kernel.org/show_bug.cgi?id=6502
Summary: SIOCSIFHWBROADCAST needs compat layer
Kernel Version: 2.6.15
Status: NEW
Severity: normal
Owner: ak@suse.de
Submitter: Alexandra.Kossovsky@oktetlabs.ru
Most recent kernel where this bug did not occur: all kernels has this problem;
I've tested 2.6.8, 2.6.9, 2.6.15
Distribution:
Hardware Environment: ethernet interface
Software Environment: 32-bit libc with 64-bit kernel
Problem Description:
32-bit program running with 64-bit kernel fails to set hardware broadcast
address via ioctl(SIOCSIFHWBROADCAST).
Steps to reproduce:
Compile the following sample program:
#include <stdio.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <linux/if.h>
main()
{
int s = socket(AF_INET, SOCK_DGRAM, 0);
struct ifreq req;
int rc;
if (s < 0)
{
perror("failed to open socket");
return -1;
}
strcpy(req.ifr_name, "eth0");
req.ifr_hwaddr.sa_family = AF_LOCAL;
memset(req.ifr_hwaddr.sa_data, 0xff, 6);
rc = ioctl(s, SIOCSIFHWBROADCAST, &req);
if (rc != 0)
{
perror("ioctl failed");
return -1;
}
printf("ioctl(SIOCSIFHWBROADCAST) passed\n");
return 0;
}
When compiled to 64-bit binary, it works OK:
ioctl(SIOCSIFHWBROADCAST) passed
When compiled to 32-bit binary, it does not work:
ioctl failed: Invalid argument
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* [PATCH] fix IP-over-ATM and ARP interaction.
From: Simon Kelley @ 2006-05-06 16:13 UTC (permalink / raw)
To: davem, netdev
The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
ARP table, using the standard neighbour-table code. The
neigh_table_init function adds this neighbour table to a linked
list of all neighbor tables which is used by the functions
neigh_delete() neigh_add() and neightbl_set(), all called by
the netlink code.
Once the ATM neighbour table is added to the list, there are two tables
with family == AF_INET there, and ARP entries sent via netlink go into
the first table with matching family. This is indeterminate and often wrong.
To see the bug, on a kernel with CLIP enabled, create a standard IPv4
ARP entry by pinging an unused address on a local subnet. Then attempt
to complete that entry by doing
ip neigh replace <ip address> lladdr <some mac address> nud reachable
Looking at the ARP tables by using
ip neigh show
will reveal two ARP entries for the same address. One of these can be
found in /proc/net/arp, and the other in /proc/net/atm/arp.
This patch adds a new function, neigh_table_init_no_netlink() which
does everything the neigh_table_init() does, except add the table to
the netlink all-arp-tables chain. In addition neigh_table_init() has a
check that all tables on the chain have a distinct address family.
The init call in clip.c is changed to call neigh_table_init_no_netlink().
Since ATM ARP tables are rather more complicated than can currently be
handled by the available rtattrs in the netlink protocol, no
functionality is lost by this patch, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr for
ATM ARP entries and some way for the netlink code to give neigh_add
and friends more information than just address family with which to find
the correct ARP table.
Signed-off-by: Simon Kelley <simon@thekelleys.org.uk>
--
diff -Naur linux-2.6.16.11.orig/include/net/neighbour.h linux-2.6.16.11/include/net/neighbour.h
--- linux-2.6.16.11.orig/include/net/neighbour.h 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/include/net/neighbour.h 2006-05-04 20:09:17.000000000 +0100
@@ -211,6 +211,7 @@
#define NEIGH_UPDATE_F_ADMIN 0x80000000
extern void neigh_table_init(struct neigh_table *tbl);
+extern void neigh_table_init_no_netlink(struct neigh_table *tbl);
extern int neigh_table_clear(struct neigh_table *tbl);
extern struct neighbour * neigh_lookup(struct neigh_table *tbl,
const void *pkey,
diff -Naur linux-2.6.16.11.orig/net/atm/clip.c linux-2.6.16.11/net/atm/clip.c
--- linux-2.6.16.11.orig/net/atm/clip.c 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/net/atm/clip.c 2006-05-04 20:10:00.000000000 +0100
@@ -995,7 +995,7 @@
static int __init atm_clip_init(void)
{
- neigh_table_init(&clip_tbl);
+ neigh_table_init_no_netlink(&clip_tbl);
clip_tbl_hook = &clip_tbl;
register_atm_ioctl(&clip_ioctl_ops);
diff -Naur linux-2.6.16.11.orig/net/core/neighbour.c linux-2.6.16.11/net/core/neighbour.c
--- linux-2.6.16.11.orig/net/core/neighbour.c 2006-04-24 21:20:24.000000000 +0100
+++ linux-2.6.16.11/net/core/neighbour.c 2006-05-04 20:07:55.000000000 +0100
@@ -1322,8 +1322,7 @@
kfree(parms);
}
-
-void neigh_table_init(struct neigh_table *tbl)
+void neigh_table_init_no_netlink(struct neigh_table *tbl)
{
unsigned long now = jiffies;
unsigned long phsize;
@@ -1381,10 +1380,19 @@
tbl->last_flush = now;
tbl->last_rand = now + tbl->parms.reachable_time * 20;
- write_lock(&neigh_tbl_lock);
- tbl->next = neigh_tables;
- neigh_tables = tbl;
- write_unlock(&neigh_tbl_lock);
+}
+
+void neigh_table_init(struct neigh_table *tbl)
+{
+ struct neigh_table *tmp;
+
+ neigh_table_init_no_netlink(tbl);
+ write_lock(&neigh_tbl_lock);
+ for (tmp = neigh_tables; tmp; tmp = tmp->next)
+ BUG_ON(tmp->family == tbl->family);
+ tbl->next = neigh_tables;
+ neigh_tables = tbl;
+ write_unlock(&neigh_tbl_lock);
}
int neigh_table_clear(struct neigh_table *tbl)
@@ -2655,6 +2663,7 @@
EXPORT_SYMBOL(neigh_resolve_output);
EXPORT_SYMBOL(neigh_table_clear);
EXPORT_SYMBOL(neigh_table_init);
+EXPORT_SYMBOL(neigh_table_init_no_netlink);
EXPORT_SYMBOL(neigh_update);
EXPORT_SYMBOL(neigh_update_hhs);
EXPORT_SYMBOL(pneigh_enqueue);
^ permalink raw reply
* 2.4 kern: want to print TCP cwnd with every packet
From: George P Nychis @ 2006-05-06 14:19 UTC (permalink / raw)
To: netdev
Hi,
I'd like to print the TCP cwnd for the sender, with every packet before it is sent out. This way i could plot the sender window over time to show TCP's behavior in certain conditions.
I see in tcp_input.c several places where i could print the current window, but i'd have to add code in multiple places. I was wondering if there is any 1 place, right before a packet is sent out, that i could printk() tp->snd_cwnd
Thanks!
George
^ permalink raw reply
* Re: Please pull upstream-fixes branch of wireless-2.6
From: John W. Linville @ 2006-05-06 13:45 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linus Torvalds, Andrew Morton, netdev, jeff
In-Reply-To: <445C2219.5060204@osdl.org>
On Fri, May 05, 2006 at 09:12:09PM -0700, Stephen Hemminger wrote:
> Linus Torvalds wrote:
> >On Fri, 5 May 2006, Andrew Morton wrote:
> >
> >>On Fri, 5 May 2006 21:06:18 -0400
> >>"John W. Linville" <linville@tuxdriver.com> wrote:
> >>
> >>>These are fixes intended for 2.6.17...thanks!
> >>>
> >>Jeff is offline for a couple of weeks. Please prepare a pull for Linus.
> >>
> >
> >Actually, while Jeff is off, Steve Hemminger is supposed to be the network
> >driver overlord ("All bow down before the mighty Shemminger"), so please
> >do synchronize with him.
> >
> >Of course, that might be just Steve taking a look and telling me "yeah,
> >please pull directly from John".
> >
> > Linus
> >
> I had a bunch ready for monday...
So, Stephen, you will pull from me and have Linus pull all from you?
Just trying to clarify the plan... :-)
It makes no difference to me. I'll include the git url "just in case":
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git upstream-fixes
Thanks!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox