* netdev munching messages again?
From: Thomas Graf @ 2005-06-07 21:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <20050607140901.632982000@axs>
Is netdev not fed regularely so it started munching messages again?
I've not received the introduction message and patches 1-5 back
only 6-7 which have been sitting in the queue due to refused
connections for a while. Am I the only one having troubles?
^ permalink raw reply
* 2.6.12-rc6-tcp1
From: Stephen Hemminger @ 2005-06-07 21:23 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Andrew Morton
http://developer.osdl.org/shemminger/patches/2.6.12-rc6-tcp1
This is the update of the TCP pluggable congestion framework with
other network changes (targeted for 2.6.13)
Minor tweaks from last time:
* move tcpdiag_put to tcp.h to avoid build problems when IP_TCPDIAG is
a module.
* sysctl tcp_congestion_control now checks for valid values
* default tcp_congestion_control is determined LIFO (ie last one registered
is the default). Sysctl just reorders list
+ added /sys/class/net/ethX/weight interface
+ added scalable TCP
- removed version patch to make integration with -mm easier
fastroute-stats-remove.patch
no-congestion.patch
no-throttle.patch
bigger-backlog.patch
fix-weightp.patch
weight-sysfs.patch
tcp_super_tso_v3.patch
tcp_infra.patch
tcp_bic.patch
tcp_westwood.patch
hstcp.patch
hybla.patch
vegas.patch
h-tcp.patch
scaleable_tcp.patch
^ permalink raw reply
* [patch] devinet: cleanup if statements
From: pmeda @ 2005-06-07 20:32 UTC (permalink / raw)
To: davem, jgarzik; +Cc: akpm, netdev
Cleanup the devinet if statements.
- when there is no colon, interface name is same as device.
- ifa_label is an array, not a pointer, and so can never be null.
Signed-Off-by: Prasanna Meda <pmeda@akamai.com>
--- a/net/ipv4/devinet.c Wed Jun 1 23:54:37 2005
+++ b/net/ipv4/devinet.c Wed Jun 1 23:57:16 2005
@@ -636,10 +636,7 @@
ret = -ENOBUFS;
if ((ifa = inet_alloc_ifa()) == NULL)
break;
- if (colon)
- memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
- else
- memcpy(ifa->ifa_label, dev->name, IFNAMSIZ);
+ memcpy(ifa->ifa_label, ifr.ifr_name, IFNAMSIZ);
} else {
ret = 0;
if (ifa->ifa_local == sin->sin_addr.s_addr)
@@ -746,10 +743,7 @@
if (len < (int) sizeof(ifr))
break;
memset(&ifr, 0, sizeof(struct ifreq));
- if (ifa->ifa_label)
- strcpy(ifr.ifr_name, ifa->ifa_label);
- else
- strcpy(ifr.ifr_name, dev->name);
+ strcpy(ifr.ifr_name, ifa->ifa_label);
(*(struct sockaddr_in *)&ifr.ifr_addr).sin_family = AF_INET;
(*(struct sockaddr_in *)&ifr.ifr_addr).sin_addr.s_addr =
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: David S. Miller @ 2005-06-07 20:21 UTC (permalink / raw)
To: john.ronciak
Cc: hadi, shemminger, mitch.a.williams, mchan, buytenh, jdmason,
netdev, Robert.Olsson, ganesh.venkatesan, jesse.brandeburg
In-Reply-To: <468F3FDA28AA87429AD807992E22D07E0450C01F@orsmsx408>
From: "Ronciak, John" <john.ronciak@intel.com>
Date: Tue, 7 Jun 2005 09:23:32 -0700
> There also seems to be some misconceptions about changing the weight
> value. It actually improves the performance of other drivers as well.
> Not as much as it improves the e1000 performance but it does seem to
> help others as well.
One reason it helps e1000 more, which Robert Olsson mentioned, could
be the HW irq mitigation settings used by the e1000 driver. Lowering
these would be a good test.
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Robert Olsson @ 2005-06-07 16:34 UTC (permalink / raw)
To: Martin Josefsson
Cc: jamal, Stephen Hemminger, Mitch Williams, Ronciak, John,
David S. Miller, mchan, buytenh, jdmason, netdev, Robert.Olsson,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <Pine.LNX.4.58.0506071432570.16594@tux.rsn.bth.se>
Martin Josefsson writes:
> > So it is possible that the e1000 is doing more than necessary share of
> > IO on the receive side as well.
>
> Yes, that's what I mean. Same thing but for RX but the question is how
> much we would gain from it, we still need to touch the rx-descriptor
> sooner or later. Would be worth a test.
> My testsetup isn't in a working condition right now, Robert?
Next week possibly... but really now idea what's to test or whats going on.
We have dual TCP server with one NIC. How is setup now? I don't know even
how it should be setup for maximum TCP performance?
How is irq affinity setup? Is irq's jumping between the CPU:s etc?
Does ksoftirq(s) use CPU? If so it can be adjusted tuned too.
How is packets processes by CPU's. /proc/net/softnet_stat. Do we see
drops w. one CPU too etc
It might be intricate question of balance between softirq and userland.
Cheers.
--ro
BTW, Can netperf be used for tests like this? (Rick?)
^ permalink raw reply
* RE: RFC: NAPI packet weighting patch
From: Ronciak, John @ 2005-06-07 16:23 UTC (permalink / raw)
To: hadi, Stephen Hemminger
Cc: Williams, Mitch A, David S. Miller, mchan, buytenh, jdmason,
netdev, Robert.Olsson, Venkatesan, Ganesh, Brandeburg, Jesse
>>
> To the intel folks: shouldnt someone be investigating why this is so?
This is why we started all of this. We have data that is showing this
issue where our over all performance is best in class and yet we can
make it better by changing things like the weight value.
There also seems to be some misconceptions about changing the weight
value. It actually improves the performance of other drivers as well.
Not as much as it improves the e1000 performance but it does seem to
help others as well. We (Intel) have to be careful talking about
competitors performance so we just refer to them as competitors in these
threads. So it is not just e1000 who benefits from the lower weight
values. One thing it is doing for e1000 right now is that it is
stopping the e1000 from dropping frames which is part of why it's
helping the e1000 more (I think).
I agree that we need to bottom out on this and it's why we are
dedicating the time and resources to this effort. We also appreciate
all the effort to help resolve this as well. This should result in a
better performing 2.6 stack and drivers. The new TSO code is a big step
in that direction as well.
Cheers,
John
^ permalink raw reply
* Re: 2.6.12-rcx networking oops
From: Phil Oester @ 2005-06-07 15:34 UTC (permalink / raw)
To: randy_dunlap; +Cc: herbert, netdev, akpm
In-Reply-To: <20050606224646.24af30ff.rdunlap@xenotime.net>
On Mon, Jun 06, 2005 at 10:46:46PM -0700, randy_dunlap wrote:
> Agreed, the stack trace is suspicious. (more below)
Yes, many of the oops i've collected are questionable...
> This is with NAPI, right? Would it make sense to try it with that
> disabled? (I don't recall you saying it's NAPI, but the e1000
> functions seem to indicate that.)
It is NAPI, but it works fine up to 2.6.11-rc1. 2.6.11-rc2 fails,
so I'm now testing each individual -bk snapshot between them in
hopes of finding the offending changeset. Given that this box
is a firewall, it could be the slew of large netfilter changes
which went into -rc2, but we'll see.
> and how about enabling CONFIG_FRAME_POINTER ?
It is enabled.
Phil
^ permalink raw reply
* [PATCH 7/7] [PKT_SCHED]: noop/noqueue qdisc style cleanups
From: Thomas Graf @ 2005-06-07 14:08 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20050607140842.778143000@axs>
[-- Attachment #1: sch_generic_cleanups --]
[-- Type: text/plain, Size: 1353 bytes --]
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: net-2.6.13/net/sched/sch_generic.c
===================================================================
--- net-2.6.13.orig/net/sched/sch_generic.c
+++ net-2.6.13/net/sched/sch_generic.c
@@ -243,31 +243,27 @@ static void dev_watchdog_down(struct net
cheaper.
*/
-static int
-noop_enqueue(struct sk_buff *skb, struct Qdisc * qdisc)
+static int noop_enqueue(struct sk_buff *skb, struct Qdisc * qdisc)
{
kfree_skb(skb);
return NET_XMIT_CN;
}
-static struct sk_buff *
-noop_dequeue(struct Qdisc * qdisc)
+static struct sk_buff *noop_dequeue(struct Qdisc * qdisc)
{
return NULL;
}
-static int
-noop_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
+static int noop_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
{
if (net_ratelimit())
- printk(KERN_DEBUG "%s deferred output. It is buggy.\n", skb->dev->name);
+ printk(KERN_DEBUG "%s deferred output. It is buggy.\n",
+ skb->dev->name);
kfree_skb(skb);
return NET_XMIT_CN;
}
struct Qdisc_ops noop_qdisc_ops = {
- .next = NULL,
- .cl_ops = NULL,
.id = "noop",
.priv_size = 0,
.enqueue = noop_enqueue,
@@ -285,8 +281,6 @@ struct Qdisc noop_qdisc = {
};
static struct Qdisc_ops noqueue_qdisc_ops = {
- .next = NULL,
- .cl_ops = NULL,
.id = "noqueue",
.priv_size = 0,
.enqueue = noop_enqueue,
^ permalink raw reply
* [PATCH 6/7] [PKT_SCHED]: Cleanup pfifo_fast qdisc and remove unnecessary code
From: Thomas Graf @ 2005-06-07 14:08 UTC (permalink / raw)
To: davem; +Cc: netdev
In-Reply-To: <20050607140842.778143000@axs>
[-- Attachment #1: sch_pfifo_fast_cleanup --]
[-- Type: text/plain, Size: 3141 bytes --]
Removes the skb trimming code which is not needed since we never
touch the skb upon failure. Removes unnecessary initializers,
and simplifies the code a bit.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Index: net-2.6.13/net/sched/sch_generic.c
===================================================================
--- net-2.6.13.orig/net/sched/sch_generic.c
+++ net-2.6.13/net/sched/sch_generic.c
@@ -311,6 +311,8 @@ static const u8 prio2band[TC_PRIO_MAX+1]
generic prio+fifo combination.
*/
+#define PFIFO_FAST_BANDS 3
+
static inline struct sk_buff_head *prio2list(struct sk_buff *skb,
struct Qdisc *qdisc)
{
@@ -318,8 +320,7 @@ static inline struct sk_buff_head *prio2
return list + prio2band[skb->priority & TC_PRIO_MAX];
}
-static int
-pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc* qdisc)
+static int pfifo_fast_enqueue(struct sk_buff *skb, struct Qdisc* qdisc)
{
struct sk_buff_head *list = prio2list(skb, qdisc);
@@ -331,36 +332,34 @@ pfifo_fast_enqueue(struct sk_buff *skb,
return qdisc_drop(skb, qdisc);
}
-static struct sk_buff *
-pfifo_fast_dequeue(struct Qdisc* qdisc)
+static struct sk_buff *pfifo_fast_dequeue(struct Qdisc* qdisc)
{
int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
- for (prio = 0; prio < 3; prio++, list++) {
+ for (prio = 0; prio < PFIFO_FAST_BANDS; prio++, list++) {
struct sk_buff *skb = __qdisc_dequeue_head(qdisc, list);
if (skb) {
qdisc->q.qlen--;
return skb;
}
}
+
return NULL;
}
-static int
-pfifo_fast_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
+static int pfifo_fast_requeue(struct sk_buff *skb, struct Qdisc* qdisc)
{
qdisc->q.qlen++;
return __qdisc_requeue(skb, qdisc, prio2list(skb, qdisc));
}
-static void
-pfifo_fast_reset(struct Qdisc* qdisc)
+static void pfifo_fast_reset(struct Qdisc* qdisc)
{
int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
- for (prio=0; prio < 3; prio++)
+ for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
__qdisc_reset_queue(qdisc, list + prio);
qdisc->qstats.backlog = 0;
@@ -369,35 +368,30 @@ pfifo_fast_reset(struct Qdisc* qdisc)
static int pfifo_fast_dump(struct Qdisc *qdisc, struct sk_buff *skb)
{
- unsigned char *b = skb->tail;
- struct tc_prio_qopt opt;
+ struct tc_prio_qopt opt = { .bands = PFIFO_FAST_BANDS };
- opt.bands = 3;
memcpy(&opt.priomap, prio2band, TC_PRIO_MAX+1);
RTA_PUT(skb, TCA_OPTIONS, sizeof(opt), &opt);
return skb->len;
rtattr_failure:
- skb_trim(skb, b - skb->data);
return -1;
}
static int pfifo_fast_init(struct Qdisc *qdisc, struct rtattr *opt)
{
- int i;
+ int prio;
struct sk_buff_head *list = qdisc_priv(qdisc);
- for (i=0; i<3; i++)
- skb_queue_head_init(list+i);
+ for (prio = 0; prio < PFIFO_FAST_BANDS; prio++)
+ skb_queue_head_init(list + prio);
return 0;
}
static struct Qdisc_ops pfifo_fast_ops = {
- .next = NULL,
- .cl_ops = NULL,
.id = "pfifo_fast",
- .priv_size = 3 * sizeof(struct sk_buff_head),
+ .priv_size = PFIFO_FAST_BANDS * sizeof(struct sk_buff_head),
.enqueue = pfifo_fast_enqueue,
.dequeue = pfifo_fast_dequeue,
.requeue = pfifo_fast_requeue,
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: jamal @ 2005-06-07 13:29 UTC (permalink / raw)
To: Martin Josefsson
Cc: Stephen Hemminger, Mitch Williams, Ronciak, John, David S. Miller,
mchan, buytenh, jdmason, netdev, Robert.Olsson,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <Pine.LNX.4.58.0506071351080.16594@tux.rsn.bth.se>
On Tue, 2005-07-06 at 14:06 +0200, Martin Josefsson wrote:
> One thing that jumps to mind is that e1000 starts at lastrxdescriptor+1
> and loops and checks the status of each descriptor and stops when it finds
> a descriptor that isn't finished. Another way to do it is to read out the
> current position of the ring and loop from lastrxdescriptor+1 up to the
> current position. Scott Feldman implemented this for TX and there it
> increased performance somewhat (discussed here on netdev some months ago).
> I wonder if it could also decrease RX latency, I mean, we have to get the
> cache miss sometime anyway.
>
The effect of Scotts patch was to reduce IO by amortizing it on the TX
side. Are we talking about the same thing ? This was in the case of TX
descriptor prunning?
So it is possible that the e1000 is doing more than necessary share of
IO on the receive side as well.
cheers,
jamal
^ permalink raw reply
* Re: [3/9] ieee80211: fix ipw 64bit compilation warnings
From: Jiri Benc @ 2005-06-07 12:58 UTC (permalink / raw)
To: NetDev; +Cc: Zhu Yi, Jeff Garzik, Jirka Bohac
In-Reply-To: <1118039392.5702.30.camel@debian.sh.intel.com>
On Mon, 06 Jun 2005 14:29:52 +0800, Zhu Yi wrote:
> ("%zd", sizeof()) should be better.
Thanks. This is a corrected version of the patch.
This patch fixes warnings when compiling ipw2100 and ipw2200 on x86_64.
Signed-off-by: Jiri Benc <jbenc@suse.cz>
Signed-off-by: Jirka Bohac <jbohac@suse.cz>
Index: netdev/drivers/net/wireless/ipw2200.c
===================================================================
--- netdev.orig/drivers/net/wireless/ipw2200.c 2005-06-01 11:03:37.000000000 +0200
+++ netdev/drivers/net/wireless/ipw2200.c 2005-06-07 14:23:08.000000000 +0200
@@ -241,8 +241,8 @@
IPW_DEBUG_IO(" reg = 0x%8X : value = 0x%8X\n", reg, value);
_ipw_write32(priv, CX2_INDIRECT_ADDR, reg & CX2_INDIRECT_ADDR_MASK);
_ipw_write8(priv, CX2_INDIRECT_DATA, value);
- IPW_DEBUG_IO(" reg = 0x%8X : value = 0x%8X\n",
- (unsigned)(priv->hw_base + CX2_INDIRECT_DATA),
+ IPW_DEBUG_IO(" reg = 0x%8lX : value = 0x%8X\n",
+ (unsigned long)(priv->hw_base + CX2_INDIRECT_DATA),
value);
}
@@ -508,7 +508,7 @@
/* verify we have enough room to store the value */
if (*len < sizeof(u32)) {
IPW_DEBUG_ORD("ordinal buffer length too small, "
- "need %d\n", sizeof(u32));
+ "need %zd\n", sizeof(u32));
return -EINVAL;
}
@@ -541,7 +541,7 @@
/* verify we have enough room to store the value */
if (*len < sizeof(u32)) {
IPW_DEBUG_ORD("ordinal buffer length too small, "
- "need %d\n", sizeof(u32));
+ "need %zd\n", sizeof(u32));
return -EINVAL;
}
@@ -1740,7 +1740,7 @@
u32 address = CX2_SHARED_SRAM_DMA_CONTROL + (sizeof(struct command_block) * index);
IPW_DEBUG_FW(">> :\n");
- ipw_write_indirect(priv, address, (u8*)cb, sizeof(struct command_block));
+ ipw_write_indirect(priv, address, (u8*)cb, (int)sizeof(struct command_block));
IPW_DEBUG_FW("<< :\n");
return 0;
@@ -2342,7 +2342,7 @@
return -EINVAL;
}
- IPW_DEBUG_INFO("Loading firmware '%s' file v%d.%d (%d bytes)\n",
+ IPW_DEBUG_INFO("Loading firmware '%s' file v%d.%d (%zd bytes)\n",
name,
IPW_FW_MAJOR(header->version),
IPW_FW_MINOR(header->version),
@@ -2697,7 +2697,7 @@
q->bd = pci_alloc_consistent(dev,sizeof(q->bd[0])*count, &q->q.dma_addr);
if (!q->bd) {
- IPW_ERROR("pci_alloc_consistent(%d) failed\n",
+ IPW_ERROR("pci_alloc_consistent(%zd) failed\n",
sizeof(q->bd[0]) * count);
kfree(q->txb);
q->txb = NULL;
@@ -3466,8 +3466,8 @@
x->channel_num);
} else {
IPW_DEBUG_SCAN("Scan result of wrong size %d "
- "(should be %d)\n",
- notif->size,sizeof(*x));
+ "(should be %zd)\n",
+ notif->size, sizeof(*x));
}
break;
}
@@ -3482,8 +3482,8 @@
x->status);
} else {
IPW_ERROR("Scan completed of wrong size %d "
- "(should be %d)\n",
- notif->size,sizeof(*x));
+ "(should be %zd)\n",
+ notif->size, sizeof(*x));
}
priv->status &= ~(STATUS_SCANNING | STATUS_SCAN_ABORTING);
@@ -3515,7 +3515,7 @@
IPW_ERROR("Frag length: %d\n", x->frag_length);
} else {
IPW_ERROR("Frag length of wrong size %d "
- "(should be %d)\n",
+ "(should be %zd)\n",
notif->size, sizeof(*x));
}
break;
@@ -3532,8 +3532,8 @@
memcpy(&priv->last_link_deterioration, x, sizeof(*x));
} else {
IPW_ERROR("Link Deterioration of wrong size %d "
- "(should be %d)\n",
- notif->size,sizeof(*x));
+ "(should be %zd)\n",
+ notif->size, sizeof(*x));
}
break;
}
@@ -3552,7 +3552,7 @@
struct notif_beacon_state *x = ¬if->u.beacon_state;
if (notif->size != sizeof(*x)) {
IPW_ERROR("Beacon state of wrong size %d (should "
- "be %d)\n", notif->size, sizeof(*x));
+ "be %zd)\n", notif->size, sizeof(*x));
break;
}
@@ -3602,8 +3602,8 @@
break;
}
- IPW_ERROR("TGi Tx Key of wrong size %d (should be %d)\n",
- notif->size,sizeof(*x));
+ IPW_ERROR("TGi Tx Key of wrong size %d (should be %zd)\n",
+ notif->size, sizeof(*x));
break;
}
@@ -3616,8 +3616,8 @@
break;
}
- IPW_ERROR("Calibration of wrong size %d (should be %d)\n",
- notif->size,sizeof(*x));
+ IPW_ERROR("Calibration of wrong size %d (should be %zd)\n",
+ notif->size, sizeof(*x));
break;
}
@@ -3628,7 +3628,7 @@
break;
}
- IPW_ERROR("Noise stat is wrong size %d (should be %d)\n",
+ IPW_ERROR("Noise stat is wrong size %d (should be %zd)\n",
notif->size, sizeof(u32));
break;
}
@@ -4823,7 +4823,7 @@
}
/* Advance skb->data to the start of the actual payload */
- skb_reserve(rxb->skb, (u32)&pkt->u.frame.data[0] - (u32)pkt);
+ skb_reserve(rxb->skb, offsetof(struct ipw_rx_packet, u.frame.data));
/* Set the size of the skb to the size of the frame */
skb_put(rxb->skb, pkt->u.frame.length);
Index: netdev/drivers/net/wireless/ipw2100.c
===================================================================
--- netdev.orig/drivers/net/wireless/ipw2100.c 2005-06-01 11:03:37.000000000 +0200
+++ netdev/drivers/net/wireless/ipw2100.c 2005-06-07 14:29:13.000000000 +0200
@@ -493,7 +493,7 @@
*len = IPW_ORD_TAB_1_ENTRY_SIZE;
IPW_DEBUG_WARNING(DRV_NAME
- ": ordinal buffer length too small, need %d\n",
+ ": ordinal buffer length too small, need %zd\n",
IPW_ORD_TAB_1_ENTRY_SIZE);
return -EINVAL;
@@ -2302,7 +2302,7 @@
#endif
IPW_DEBUG_INFO(DRV_NAME ": PCI latency error detected at "
- "0x%04X.\n", i * sizeof(struct ipw2100_status));
+ "0x%04zX.\n", i * sizeof(struct ipw2100_status));
#ifdef ACPI_CSTATE_LIMIT_DEFINED
IPW_DEBUG_INFO(DRV_NAME ": Disabling C3 transitions.\n");
@@ -2398,7 +2398,7 @@
/* Make a copy of the frame so we can dump it to the logs if
* ieee80211_rx fails */
memcpy(packet_data, packet->skb->data,
- min(status->frame_size, IPW_RX_NIC_BUFFER_LENGTH));
+ min_t(u32, status->frame_size, IPW_RX_NIC_BUFFER_LENGTH));
#endif
if (!ieee80211_rx(priv->ieee, packet->skb, stats)) {
@@ -2730,21 +2730,21 @@
{
int i = txq->oldest;
IPW_DEBUG_TX(
- "TX%d V=%p P=%p T=%p L=%d\n", i,
+ "TX%d V=%p P=%04X T=%04X L=%d\n", i,
&txq->drv[i],
- (void*)txq->nic + i * sizeof(struct ipw2100_bd),
- (void*)txq->drv[i].host_addr,
+ (u32)(txq->nic + i * sizeof(struct ipw2100_bd)),
+ txq->drv[i].host_addr,
txq->drv[i].buf_length);
if (packet->type == DATA) {
i = (i + 1) % txq->entries;
IPW_DEBUG_TX(
- "TX%d V=%p P=%p T=%p L=%d\n", i,
+ "TX%d V=%p P=%04X T=%04X L=%d\n", i,
&txq->drv[i],
- (void*)txq->nic + i *
- sizeof(struct ipw2100_bd),
- (void*)txq->drv[i].host_addr,
+ (u32)(txq->nic + i *
+ sizeof(struct ipw2100_bd)),
+ (u32)txq->drv[i].host_addr,
txq->drv[i].buf_length);
}
}
@@ -4212,7 +4212,7 @@
{
IPW_DEBUG_INFO("enter\n");
- IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, q->nic);
+ IPW_DEBUG_INFO("initializing bd queue at virt=%p, phys=%08x\n", q->drv, (u32)q->nic);
write_register(priv->net_dev, base, q->nic);
write_register(priv->net_dev, size, q->entries);
@@ -8431,7 +8431,7 @@
priv->net_dev->name, fw_name);
return rc;
}
- IPW_DEBUG_INFO("firmware data %p size %d\n", fw->fw_entry->data,
+ IPW_DEBUG_INFO("firmware data %p size %zd\n", fw->fw_entry->data,
fw->fw_entry->size);
ipw2100_mod_firmware_load(fw);
--
Jiri Benc
SUSE Labs
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: jamal @ 2005-06-07 12:38 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Mitch Williams, Ronciak, John, David S. Miller, mchan, buytenh,
jdmason, netdev, Robert.Olsson, Venkatesan, Ganesh,
Brandeburg, Jesse
In-Reply-To: <42A5284C.3060808@osdl.org>
On Mon, 2005-06-06 at 21:53 -0700, Stephen Hemminger wrote:
> I noticed that the tg3 driver copies packets less than a certain
> threshold to a new buffer, but e1000 always passes the big buffer up
> the stack. Could this be having an impact?
It is possible. Remember also the cost of IO these days is worse than a
cache miss in cycles as well as absolute time. So the e1000 maybe doing
more IO than the tg3.
I think there is something fishy about the e1000 in general; From what i
just heard mentioned reading the emails is there's improvement if the rx
ring is replenished on a per packet basis instead of a batch at the end.
This somehow is not an issue with tg3. I think doing replenishing in
smaller batches like 5 packets at a time would also help.
That the tg3 doesnt need to have its rx ring sizes adjusted but the
e1000 gets better the lower the rx ring size is strange.
To the intel folks: shouldnt someone be investigating why this is so?
Fixing the effect with "lets lower the weight" or "wait, lets adjust it
at runtime" because we know it fixes our problem - sounds like a serious
bandaid to me. Lets find the cause and fix that instead.
Why is this issue happening with e1000? Thats what needs to be resolved.
So far some evidence seems to be suggesting that the tg3 uses less CPU.
cheers,
jamal
^ permalink raw reply
* Re: 2.4.30-hf1 do_IRQ stack overflows
From: Manfred Schwarb @ 2005-06-07 12:38 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: linux-kernel, davem, netdev, herbert
In-Reply-To: <20050511124640.GE8541@logos.cnet>
>
> Hi Manfred,
>
> On Wed, May 11, 2005 at 10:15:02AM +0200, Manfred Schwarb wrote:
> > Hi,
> > with recent versions of the 2.4 kernel (Vanilla), I get an increasing
> amount of do_IRQ stack overflows.
> > This night, I got 3 of them.
> > With 2.4.28 I got an overflow about twice a year, with 2.4.29 nearly
> once a month and with
> > 2.4.30 nearly every day 8-((
>
> The system is getting dangerously close to an actual stack overflow, which
> would
> crash the system.
>
> "do_IRQ: stack overflow: " indicates how many bytes are still available.
>
> The traces show huge networking execution paths.
>
> It seems you are using some packet scheduler (CONFIG_NET_SCHED)? Pretty
> much all
> traces show functions from sch_generic.c. Can you disable that for a test?
>
Sorry to bother you again, but the problem didn't vanish completely.
This morning, I caught another one. I built a new kernel with
CONFIG_NET_SCHED=n as suggested, uptime is now 25 days, and the following
is the first do_IRQ since then (ksymoops -i):
Jun 7 03:55:01 tp-meteodat7 kernel: f3238830 00000280 f49e7b80 00000000
00000042 cca1388e f4116980 f17aa000
Jun 7 03:55:01 tp-meteodat7 kernel: c010d948 00000042 f4116980
00000000 cca1388e f4116980 f17aa000 00000042
Jun 7 03:55:01 tp-meteodat7 kernel: 00000018 f61d0018 ffffff14
c023a039 00000010 00000246 ee5ea480 00000000
Jun 7 03:55:01 tp-meteodat7 kernel: Call Trace: [call_do_IRQ+5/13]
[skb_copy_and_csum_dev+73/256]
[nfsd:__insmod_nfsd_O/lib/modules/2.4.30-hf1/kernel/fs/nfsd/nfsd.+4256445916/96]
[qdisc_restart+114/432] [dev_queue_xmit+383/880]
Jun 7 03:55:01 tp-meteodat7 kernel: Call Trace: [<c010d948>]
[<c023a039>] [<f90df5dc>] [<c0248402>] [<c023cc7f>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02561a8>] [<c02560f0>]
[<c02560f0>] [<c024760e>] [<c02560f0>] [<c025492e>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02560f0>] [<c0256315>]
[<c0256240>] [<c0256240>] [<c024760e>] [<c0256240>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0254d0d>] [<c0256240>]
[<c026daf0>] [<c0267c99>] [<c026a6f4>] [<c0259370>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0259370>] [<c02661ca>]
[<c026edaa>] [<c026f48e>] [<c025174f>] [<c02515f0>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c024760e>] [<c02515f0>]
[<c0251790>] [<c02510df>] [<c02515f0>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0251969>] [<c0251790>]
[<c024760e>] [<c0251790>] [<c02514b8>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c023d4d5>] [<c023d5a3>]
[<c023d73a>] [<c01254c6>] [<c010b094>] [<c010d948>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c010a625>] [<c011ce8a>]
[<c011cb14>] [<c011ca60>] [<f90f2697>] [<f90f27f9>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f90f28ab>] [<f90f40c6>]
[<f914f588>] [<f915053e>] [<f9151255>] [<f8b3a3c4>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b4bcf0>] [<f8b3a3c4>]
[<f8b4d80f>] [<f8b3a3c4>] [<f8b3a3c4>] [<f8b4cc74>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b3a3c4>] [<f8b39e28>]
[<f8b448c3>] [<f8b4f8c3>] [<f8b4667b>] [<f8b3a308>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<f8b465ad>] [<f8b531fc>]
[<c02387b6>] [<f90df5f4>] [<c02483af>] [<c023cc7f>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02561a8>] [<c02387b6>]
[<f90df5f4>] [<c02387b6>] [<f90df5f4>] [<c02483af>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02560f0>] [<c02560f0>]
[<c024760e>] [<c02560f0>] [<c025492e>] [<c02560f0>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0256315>] [<c0237f63>]
[<c0259370>] [<c0259370>] [<c026618d>] [<c026edaa>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c026f48e>] [<c025174f>]
[<c02515f0>] [<c024760e>] [<c02515f0>] [<c0251790>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c02510df>] [<c02515f0>]
[<c0251790>] [<c0251969>] [<c0251790>] [<c024760e>]
Jun 7 03:55:01 tp-meteodat7 kernel: [<c0251790>] [<c013e624>]
[<c01594d4>] [<c01598d9>] [<c0159bb4>] [<c0158905>]
Warning (Oops_read): Code line not seen, dumping what data is available
Trace; c010d948 <call_do_IRQ+5/d>
Trace; c023a039 <skb_copy_and_csum_dev+49/100>
Trace; f90df5dc <[8139too]rtl8139_start_xmit+6c/180>
Trace; c0248402 <qdisc_restart+72/1b0>
Trace; c023cc7f <dev_queue_xmit+17f/370>
Trace; c02561a8 <ip_finish_output2+b8/150>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c025492e <ip_output+14e/1e0>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c0256315 <ip_queue_xmit2+d5/29f>
Trace; c0256240 <ip_queue_xmit2+0/29f>
Trace; c0256240 <ip_queue_xmit2+0/29f>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c0256240 <ip_queue_xmit2+0/29f>
Trace; c0254d0d <ip_queue_xmit+34d/600>
Trace; c0256240 <ip_queue_xmit2+0/29f>
Trace; c026daf0 <tcp_v4_send_check+a0/f0>
Trace; c0267c99 <tcp_transmit_skb+3e9/700>
Trace; c026a6f4 <tcp_send_ack+84/d0>
Trace; c0259370 <tcp_rfree+0/20>
Trace; c0259370 <tcp_rfree+0/20>
Trace; c02661ca <tcp_rcv_established+7fa/a50>
Trace; c026edaa <tcp_v4_do_rcv+13a/160>
Trace; c026f48e <tcp_v4_rcv+6be/7a0>
Trace; c025174f <ip_local_deliver_finish+15f/1a0>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c02510df <ip_local_deliver+18f/240>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c0251969 <ip_rcv_finish+1d9/268>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c02514b8 <ip_rcv+328/460>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c023d4d5 <netif_receive_skb+1e5/220>
Trace; c023d5a3 <process_backlog+93/130>
Trace; c023d73a <net_rx_action+fa/170>
Trace; c01254c6 <do_softirq+76/e0>
Trace; c010b094 <do_IRQ+f4/130>
Trace; c010d948 <call_do_IRQ+5/d>
Trace; c010a625 <set_ldt_desc+5/3b>
Trace; c011ce8a <schedule+28a/540>
Trace; c011cb14 <schedule_timeout+54/a0>
Trace; c011ca60 <process_timeout+0/60>
Trace; f90f2697 <[usbcore]usb_start_wait_urb+a7/1a0>
Trace; f90f27f9 <[usbcore]usb_internal_control_msg+69/80>
Trace; f90f28ab <[usbcore]usb_control_msg+9b/b0>
Trace; f90f40c6 <[usbcore]usb_get_report+76/80>
Trace; f914f588 <[hid]hid_read_report+98/c0>
Trace; f915053e <[hid]hiddev_lookup_report+9e/c0>
Trace; f9151255 <[hid]hiddev_ioctl+565/cd0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4bcf0 <[reiserfs]leaf_copy_items_entirely+1c0/250>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4d80f <[reiserfs]leaf_delete_items_entirely+16f/250>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b4cc74 <[reiserfs]leaf_insert_into_buf+1c4/2c0>
Trace; f8b3a3c4 <[reiserfs]do_balance_mark_leaf_dirty+64/a0>
Trace; f8b39e28 <[reiserfs]balance_leaf+30a8/3120>
Trace; f8b448c3 <[reiserfs]ip_check_balance+2e3/bf0>
Trace; f8b4f8c3 <[reiserfs]pathrelse_and_restore+43/60>
Trace; f8b4667b <[reiserfs]unfix_nodes+9b/180>
Trace; f8b3a308 <[reiserfs]do_balance+d8/130>
Trace; f8b465ad <[reiserfs]fix_nodes+3fd/430>
Trace; f8b531fc <[reiserfs]reiserfs_insert_item+14c/150>
Trace; c02387b6 <__kfree_skb+f6/150>
Trace; f90df5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483af <qdisc_restart+1f/1b0>
Trace; c023cc7f <dev_queue_xmit+17f/370>
Trace; c02561a8 <ip_finish_output2+b8/150>
Trace; c02387b6 <__kfree_skb+f6/150>
Trace; f90df5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02387b6 <__kfree_skb+f6/150>
Trace; f90df5f4 <[8139too]rtl8139_start_xmit+84/180>
Trace; c02483af <qdisc_restart+1f/1b0>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c025492e <ip_output+14e/1e0>
Trace; c02560f0 <ip_finish_output2+0/150>
Trace; c0256315 <ip_queue_xmit2+d5/29f>
Trace; c0237f63 <sock_def_readable+63/80>
Trace; c0259370 <tcp_rfree+0/20>
Trace; c0259370 <tcp_rfree+0/20>
Trace; c026618d <tcp_rcv_established+7bd/a50>
Trace; c026edaa <tcp_v4_do_rcv+13a/160>
Trace; c026f48e <tcp_v4_rcv+6be/7a0>
Trace; c025174f <ip_local_deliver_finish+15f/1a0>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c02510df <ip_local_deliver+18f/240>
Trace; c02515f0 <ip_local_deliver_finish+0/1a0>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c0251969 <ip_rcv_finish+1d9/268>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c024760e <nf_hook_slow+1de/210>
Trace; c0251790 <ip_rcv_finish+0/268>
Trace; c013e624 <__alloc_pages+64/280>
Trace; c01594d4 <poll_freewait+44/50>
Trace; c01598d9 <do_select+239/250>
Trace; c0159bb4 <sys_select+294/4e0>
Trace; c0158905 <sys_ioctl+2a5/311>
--
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Martin Josefsson @ 2005-06-07 12:36 UTC (permalink / raw)
To: jamal
Cc: Stephen Hemminger, Mitch Williams, Ronciak, John, David S. Miller,
mchan, buytenh, jdmason, netdev, Robert.Olsson,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <1118150948.6320.152.camel@localhost.localdomain>
On Tue, 7 Jun 2005, jamal wrote:
> On Tue, 2005-07-06 at 14:06 +0200, Martin Josefsson wrote:
>
> > One thing that jumps to mind is that e1000 starts at lastrxdescriptor+1
> > and loops and checks the status of each descriptor and stops when it finds
> > a descriptor that isn't finished. Another way to do it is to read out the
> > current position of the ring and loop from lastrxdescriptor+1 up to the
> > current position. Scott Feldman implemented this for TX and there it
> > increased performance somewhat (discussed here on netdev some months ago).
> > I wonder if it could also decrease RX latency, I mean, we have to get the
> > cache miss sometime anyway.
> >
>
> The effect of Scotts patch was to reduce IO by amortizing it on the TX
> side. Are we talking about the same thing ? This was in the case of TX
> descriptor prunning?
Yes, that was for TX pruning.
> So it is possible that the e1000 is doing more than necessary share of
> IO on the receive side as well.
Yes, that's what I mean. Same thing but for RX but the question is how
much we would gain from it, we still need to touch the rx-descriptor
sooner or later. Would be worth a test.
My testsetup isn't in a working condition right now, Robert?
/Martin
^ permalink raw reply
* Re: RFC: NAPI packet weighting patch
From: Martin Josefsson @ 2005-06-07 12:06 UTC (permalink / raw)
To: jamal
Cc: Stephen Hemminger, Mitch Williams, Ronciak, John, David S. Miller,
mchan, buytenh, jdmason, netdev, Robert.Olsson,
Venkatesan, Ganesh, Brandeburg, Jesse
In-Reply-To: <1118147904.6320.108.camel@localhost.localdomain>
On Tue, 7 Jun 2005, jamal wrote:
> It is possible. Remember also the cost of IO these days is worse than a
> cache miss in cycles as well as absolute time. So the e1000 maybe doing
> more IO than the tg3.
>
> I think there is something fishy about the e1000 in general; From what i
> just heard mentioned reading the emails is there's improvement if the rx
> ring is replenished on a per packet basis instead of a batch at the end.
> This somehow is not an issue with tg3. I think doing replenishing in
> smaller batches like 5 packets at a time would also help.
> That the tg3 doesnt need to have its rx ring sizes adjusted but the
> e1000 gets better the lower the rx ring size is strange.
>
> To the intel folks: shouldnt someone be investigating why this is so?
>
> Fixing the effect with "lets lower the weight" or "wait, lets adjust it
> at runtime" because we know it fixes our problem - sounds like a serious
> bandaid to me. Lets find the cause and fix that instead.
> Why is this issue happening with e1000? Thats what needs to be resolved.
> So far some evidence seems to be suggesting that the tg3 uses less CPU.
One thing that jumps to mind is that e1000 starts at lastrxdescriptor+1
and loops and checks the status of each descriptor and stops when it finds
a descriptor that isn't finished. Another way to do it is to read out the
current position of the ring and loop from lastrxdescriptor+1 up to the
current position. Scott Feldman implemented this for TX and there it
increased performance somewhat (discussed here on netdev some months ago).
I wonder if it could also decrease RX latency, I mean, we have to get the
cache miss sometime anyway.
I havn't checked how tg3 does it.
/Martin
^ permalink raw reply
* Re: [PATCH]: Tigon3 new NAPI locking v2
From: Greg Banks @ 2005-06-07 10:11 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Network Development list, mchan
In-Reply-To: <20050603.122558.88474819.davem@davemloft.net>
On Sat, 2005-06-04 at 05:25, David S. Miller wrote:
> This version incorporates two bug fixes from Michael.
>
> 1) Check the mailbox register for 0x1 while polling on the COMPLETE
> state bit.
>
> 2) Remove the BUG_ON() check in tg3_restart_ints(), it can legally and
> harmlessly occur.
>
> Point #2 may want some refinements, but this patch below is good
> enough for testing.
This patch seems to run well, so far without the lockup we saw
with the first version. It really helps with irq fairness when
we have lots of tg3 and Fibre Channel HBA interrupts going to the
same CPU.
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
^ permalink raw reply
* Re: [PATCH 1/1] sysctl configurable icmperror sourceaddress
From: J. Simonetti @ 2005-06-07 9:40 UTC (permalink / raw)
To: netdev
In-Reply-To: <1118136384.10479.15.camel@jeroens.office.netland.nl>
[-- Attachment #1: Type: text/plain, Size: 337 bytes --]
On Tue, 2005-06-07 at 11:26 +0200, J. Simonetti wrote:
> This patch alows you to change the source address of icmp error
> messages. It applies cleanly to 2.6.11.11 and retains the default
> behaviour.
I swear I had attached it... really... ;)
Jeroen Simonetti
--
character density, n.:
The number of very weird people in the office.
[-- Attachment #2: linux-2.6.11.11-icmperrors.patch --]
[-- Type: text/x-patch, Size: 1807 bytes --]
--- include/linux/sysctl.h.orig 2004-12-24 22:34:58.000000000 +0100
+++ include/linux/sysctl.h 2005-06-07 10:16:39.730585288 +0200
@@ -345,6 +345,7 @@
NET_TCP_MODERATE_RCVBUF=106,
NET_TCP_TSO_WIN_DIVISOR=107,
NET_TCP_BIC_BETA=108,
+ NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR=109,
};
enum {
--- net/ipv4/icmp.c.orig 2004-12-24 22:35:28.000000000 +0100
+++ net/ipv4/icmp.c 2005-06-07 10:15:42.645263576 +0200
@@ -207,6 +207,7 @@
int sysctl_icmp_ratelimit = 1 * HZ;
int sysctl_icmp_ratemask = 0x1818;
+int sysctl_icmp_errors_use_inbound_ifaddr = 0;
/*
* ICMP control array. This specifies what to do with each ICMP.
@@ -511,8 +512,12 @@
*/
saddr = iph->daddr;
- if (!(rt->rt_flags & RTCF_LOCAL))
- saddr = 0;
+ if (!(rt->rt_flags & RTCF_LOCAL)) {
+ if(sysctl_icmp_errors_use_inbound_ifaddr)
+ saddr = inet_select_addr(skb_in->dev, 0, RT_SCOPE_LINK);
+ else
+ saddr = 0;
+ }
tos = icmp_pointers[type].error ? ((iph->tos & IPTOS_TOS_MASK) |
IPTOS_PREC_INTERNETCONTROL) :
--- net/ipv4/sysctl_net_ipv4.c.orig 2004-12-24 22:35:23.000000000 +0100
+++ net/ipv4/sysctl_net_ipv4.c 2005-06-07 10:19:44.538490216 +0200
@@ -23,6 +23,7 @@
extern int sysctl_icmp_echo_ignore_all;
extern int sysctl_icmp_echo_ignore_broadcasts;
extern int sysctl_icmp_ignore_bogus_error_responses;
+extern int sysctl_icmp_errors_use_inbound_ifaddr;
/* From ip_fragment.c */
extern int sysctl_ipfrag_low_thresh;
@@ -396,6 +397,14 @@
.proc_handler = &proc_dointvec
},
{
+ .ctl_name = NET_IPV4_ICMP_ERRORS_USE_INBOUND_IFADDR,
+ .procname = "icmp_errors_use_inbound_ifaddr",
+ .data = &sysctl_icmp_errors_use_inbound_ifaddr,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
+ {
.ctl_name = NET_IPV4_ROUTE,
.procname = "route",
.maxlen = 0,
^ permalink raw reply
* [PATCH 1/1] sysctl configurable icmperror sourceaddress
From: J. Simonetti @ 2005-06-07 9:26 UTC (permalink / raw)
To: netdev
This patch alows you to change the source address of icmp error
messages. It applies cleanly to 2.6.11.11 and retains the default
behaviour.
In the old (default) behaviour icmp error messages are sent with the ip
of the exiting interface.
The new behaviour (when the sysctl variable is toggled on), it will send
the message with the ip of the interface that received the packet that
caused the icmp error. This is the behaviour network administrators will
expect from a router. It makes debugging complicated network layouts
much easier. Also, all 'vendor routers' I know of have the later
behaviour.
Regards,
Jeroen Simonetti
--
"Absolutely nothing should be concluded from these figures except that
no conclusion can be drawn from them."
(By Joseph L. Brothers, Linux/PowerPC Project)
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-07 8:14 UTC (permalink / raw)
To: dlstevens; +Cc: davem, netdev, yoshfuji
In-Reply-To: <OFB68D40CB.B0CAE212-ON88257019.002B61C8-88257019.002C0A18@us.ibm.com>
In article <OFB68D40CB.B0CAE212-ON88257019.002B61C8-88257019.002C0A18@us.ibm.com> (at Tue, 7 Jun 2005 01:01:01 -0700), David Stevens <dlstevens@us.ibm.com> says:
> Ok, but this gets back to my point. If the program source
> doesn't have #ifdefs like you suggested (for example, if
> it was written before the new API existed), then it'll still
> have an error, but that error won't show up until the next
> time it's recompiled. So, an old binary will work fine, but
> recompiling it will get EINVAL on the setsockopt() calls.
> The old binary will work, the old source will compile, but
> the new binary will not work, and may not be found until
> much later.
It is okay, we can warn that "you use old API; please fix that!"
or something like that.
(like SO_BSDCOMPAT or, neigh.XXX.base_reachable_time sysctl.)
> I think it's better to break and fix any use of these
> right away instead of delaying the error until the next
> time some old binary is recompiled and run, don't you?
No, I don't think so. Please do NOT break binary API in 2.6.x.
I think it is okay in 2.7, but I still think that it is
good to use new values for new semantics.
--yoshfuji
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: David Stevens @ 2005-06-07 8:04 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, netdev, yoshfuji
In-Reply-To: <20050607.165536.75463878.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote on 06/07/2005
12:55:36 AM:
> In article <20050607.164749.62298775.yoshfuji@linux-ipv6.org> (at Tue,
07 Jun
> 2005 16:47:49 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明
<yoshfuji@linux-ipv6.org> says:
> > No, kernel should send 5, if application use old API, of course.
> This can be implemented like this (based on codes from our repository):
> /* RFC2292bis */
> if (np->rxopt.bits.rxhbh && opt->hop) {
> u8 *ptr = skb->nh.raw + opt->hop;
> put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, (ptr[1]+1)<<3, ptr);
> }
> /* RFC2292 */
> if (np->rxopt.bits.rxhbh2292 && opt->hop) {
> u8 *ptr = skb->nh.raw + opt->hop;
> put_cmsg(msg, SOL_IPV6, IPV6_2292HOPOPTS, (ptr[1]+1)<<3, ptr);
> }
> --yoshfuji
Sure, it's easy to do. But the application that's using
it has broken source, and nobody will know until after it's
recompiled.
I'd just have a single flag for all, on the assumption that
they're either using old API exclusively, or new. But, again,
it leaves a land mine for the source bug in the application
that you're allowing to still work.
+-DLS
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: David Stevens @ 2005-06-07 8:01 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明
Cc: davem, netdev, yoshfuji
In-Reply-To: <20050607.164749.62298775.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> wrote on 06/07/2005
12:47:49 AM:
> No, kernel should send 5, if application use old API, of course.
> --yoshfuji
Ok, but this gets back to my point. If the program source
doesn't have #ifdefs like you suggested (for example, if
it was written before the new API existed), then it'll still
have an error, but that error won't show up until the next
time it's recompiled. So, an old binary will work fine, but
recompiling it will get EINVAL on the setsockopt() calls.
The old binary will work, the old source will compile, but
the new binary will not work, and may not be found until
much later.
The two API's are fundamentally incompatible, because
they have common names that do different things, and in
the first, the boolean socket option and cmsg_type must
be the same, in the second, they cannot be.
I think it's better to break and fix any use of these
right away instead of delaying the error until the next
time some old binary is recompiled and run, don't you?
+-DLS
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-07 7:55 UTC (permalink / raw)
To: dlstevens; +Cc: davem, netdev, yoshfuji
In-Reply-To: <20050607.164749.62298775.yoshfuji@linux-ipv6.org>
In article <20050607.164749.62298775.yoshfuji@linux-ipv6.org> (at Tue, 07 Jun 2005 16:47:49 +0900 (JST)), YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> says:
> No, kernel should send 5, if application use old API, of course.
This can be implemented like this (based on codes from our repository):
/* RFC2292bis */
if (np->rxopt.bits.rxhbh && opt->hop) {
u8 *ptr = skb->nh.raw + opt->hop;
put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS, (ptr[1]+1)<<3, ptr);
}
/* RFC2292 */
if (np->rxopt.bits.rxhbh2292 && opt->hop) {
u8 *ptr = skb->nh.raw + opt->hop;
put_cmsg(msg, SOL_IPV6, IPV6_2292HOPOPTS, (ptr[1]+1)<<3, ptr);
}
--yoshfuji
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-07 7:47 UTC (permalink / raw)
To: dlstevens; +Cc: davem, netdev, yoshfuji
In-Reply-To: <OF2D6866A4.ACD65B11-ON88257019.0027E8B0-88257019.002A2862@us.ibm.com>
In article <OF2D6866A4.ACD65B11-ON88257019.0027E8B0-88257019.002A2862@us.ibm.com> (at Tue, 7 Jun 2005 00:40:28 -0700), David Stevens <dlstevens@us.ibm.com> says:
> > We can still keep old binaries if we renumber.
> > This is important point.
> > e.g. people, including myself, can keep using old binaries on new
> kernels.
:
> But old binaries won't work with just that change
> (and making them work is independent of changing
> the numbers).
>
> For example, old binary:
>
> IPV6_RTHDR is value 5
>
> it does:
> on=1; setsockopt(s, SOL_IPV6, 5, &on);
> and later a recvmsg() where it looks for
> cmsg_type == IPV6_RTHDR (5).
>
> In the new API, the equivalent:
>
> IPV6_RTHDR 728
> IPV6_RECVRTHDR 729
>
> old binary calls with "5", which you want
> to work, but returns cmsg_type "728" (app doesn't
> find a "5").
No, kernel should send 5, if application use old API, of course.
--yoshfuji
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: David Stevens @ 2005-06-07 7:40 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: davem, netdev
In-Reply-To: <20050607.160521.73986501.yoshfuji@linux-ipv6.org>
> We can still keep old binaries if we renumber.
> This is important point.
> e.g. people, including myself, can keep using old binaries on new
kernels.
> --yoshfuji
But old binaries won't work with just that change
(and making them work is independent of changing
the numbers).
For example, old binary:
IPV6_RTHDR is value 5
it does:
on=1; setsockopt(s, SOL_IPV6, 5, &on);
and later a recvmsg() where it looks for
cmsg_type == IPV6_RTHDR (5).
In the new API, the equivalent:
IPV6_RTHDR 728
IPV6_RECVRTHDR 729
old binary calls with "5", which you want
to work, but returns cmsg_type "728" (app doesn't
find a "5").
The boolean socket option in the new API
cannot be equal to the cmsg_type, because IPV6_RTHDR
and IPV6_RECVRTHDR do different things as socket
options (and both are there).
So, no old binary can work unless the kernel
"knows" it's talking to an old binary, and it
returns a different (wrong, under the new API)
cmsg_type for that option. But the putcmsg() are
done in receive processing, so you'd need a flag
to tell you which you had, and a map for old and
new cmsg_type's.
But the number changes don't help here,
because an old binary will call with argument
size of int, a new binary will have an argument
greater (barring bugs). So, you can tell without
number changes, but you still have all the ugly
code to return old and new data for old and new
binaries.
And if the caller doesn't change the source,
it'll recompile fine but give incorrect results
(EINVAL on the setsockopt call) when s/he gets
the new definition of IPV6_RTHDR, but still calls
it with a boolean argument value.
I'm suggesting we bypass the ugly binary support
and get EINVAL when run now; trivial source fix,
and they have a working binary again.
+-DLS
^ permalink raw reply
* Re: IPV6 RFC3542 compliance [PATCH]
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-06-07 7:05 UTC (permalink / raw)
To: dlstevens; +Cc: davem, netdev, yoshfuji
In-Reply-To: <OF4AE6E385.33144EB9-ON88257019.0024BCE9-88257019.00258FFE@us.ibm.com>
In article <OF4AE6E385.33144EB9-ON88257019.0024BCE9-88257019.00258FFE@us.ibm.com> (at Mon, 6 Jun 2005 23:50:16 -0700), David Stevens <dlstevens@us.ibm.com> says:
> > Portable applications do like this:
>
> > #ifdef IPV6_RECVHOPOPTS
> > // RFC2292bis
> > #else
> > // RFC2292
> > #endif
>
> > --yoshfuji
>
> I don't understand. If they do this, they'll
> work already when recompiled (with the patch
> I sent), won't they?
Yes (or they should do so before your favorite distro start shipping with
new constants).
> How does it help to renumber? I can renumber,
> of course-- I just don't see how that does
> anything.
We can still keep old binaries if we renumber.
This is important point.
e.g. people, including myself, can keep using old binaries on new kernels.
--yoshfuji
^ 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