* [PATCH] improved statistics for bcm43xx-softmac
From: Larry Finger @ 2006-06-29 4:08 UTC (permalink / raw)
To: John Linville, netdev
This patch improves the statistics returned from bcm43xx_get_wireless_stats. The signal level comes
from smoothing the rssi value returned by the firmware. The quality value is a hack derived from the
smoothed rssi value and an assumed rssi_max of -25. If anyone has a better value, please let me
know. The noise value is still the one calculated from the clean-room formula. On my system, this is
roughly -65 dBm, which seems too high. I would appreciate getting any ideas on what other
interface/driver combinations get for the noise value.
Signed-Off-By: Larry Finger <Larry.Finger@lwfinger.net>
==========================================================
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index af97755..c80fdcd 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1581,17 +1581,8 @@ static void handle_irq_noise(struct bcm4
else
average -= 48;
-/* FIXME: This is wrong, but people want fancy stats. well... */
-bcm->stats.noise = average;
- if (average > -65)
- bcm->stats.link_quality = 0;
- else if (average > -75)
- bcm->stats.link_quality = 1;
- else if (average > -85)
- bcm->stats.link_quality = 2;
- else
- bcm->stats.link_quality = 3;
-// dprintk(KERN_INFO PFX "Link Quality: %u (avg was %d)\n", bcm->stats.link_quality, average);
+/* FIXME: This matches the formula from the clean-room, but yields a value that is probably too
large. */
+ bcm->stats.noise = average;
drop_calculation:
bcm->noisecalc.calculation_running = 0;
return;
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
index 5c36e29..8224da1 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_wx.c
@@ -47,6 +47,8 @@ #include "bcm43xx_phy.h"
#define BCM43xx_WX_VERSION 18
#define MAX_WX_STRING 80
+/* FIXME: the next line is a guess as to what the maximum value of rssi might be */
+#define RSSI_MAX -25
static int bcm43xx_wx_get_name(struct net_device *net_dev,
@@ -227,15 +229,15 @@ static int bcm43xx_wx_get_rangeparams(st
range->max_qual.qual = 100;
/* TODO: Real max RSSI */
- range->max_qual.level = 3;
- range->max_qual.noise = 100;
- range->max_qual.updated = 7;
-
- range->avg_qual.qual = 70;
- range->avg_qual.level = 2;
- range->avg_qual.noise = 40;
- range->avg_qual.updated = 7;
-
+ range->max_qual.level = -100;
+ range->max_qual.noise = -100;
+ range->max_qual.updated = IW_QUAL_ALL_UPDATED;
+
+ range->avg_qual.qual = 50;
+ range->avg_qual.level = -40;
+ range->avg_qual.noise = -65;
+ range->avg_qual.updated = IW_QUAL_ALL_UPDATED;
+
range->min_rts = BCM43xx_MIN_RTS_THRESHOLD;
range->max_rts = BCM43xx_MAX_RTS_THRESHOLD;
range->min_frag = MIN_FRAG_THRESHOLD;
@@ -827,6 +829,8 @@ static struct iw_statistics *bcm43xx_get
struct bcm43xx_private *bcm = bcm43xx_priv(net_dev);
struct ieee80211softmac_device *mac = ieee80211_priv(net_dev);
struct iw_statistics *wstats;
+ struct ieee80211_network *network = NULL;
+ static int tmp_level = 0;
wstats = &bcm->stats.wstats;
if (!mac->associated) {
@@ -849,11 +853,19 @@ static struct iw_statistics *bcm43xx_get
return wstats;
}
/* fill in the real statistics when iface associated */
- wstats->qual.qual = 100; // TODO: get the real signal quality
- wstats->qual.level = 3 - bcm->stats.link_quality;
+ list_for_each_entry(network, &mac->ieee->network_list, list) {
+ if (!memcmp(mac->associnfo.bssid, network->bssid, ETH_ALEN)) {
+ if (!tmp_level) /* get initial value */
+ tmp_level = network->stats.rssi;
+ else /* smooth results */
+ tmp_level = (7 * tmp_level + network->stats.rssi)/8;
+ break;
+ }
+ }
+ wstats->qual.level = tmp_level;
+ wstats->qual.qual = 100 + tmp_level - RSSI_MAX; // TODO: get the real signal quality
wstats->qual.noise = bcm->stats.noise;
- wstats->qual.updated = IW_QUAL_QUAL_UPDATED | IW_QUAL_LEVEL_UPDATED |
- IW_QUAL_NOISE_UPDATED;
+ wstats->qual.updated = IW_QUAL_ALL_UPDATED;
wstats->discard.code = bcm->ieee->ieee_stats.rx_discards_undecryptable;
wstats->discard.retries = bcm->ieee->ieee_stats.tx_retry_limit_exceeded;
wstats->discard.nwid = bcm->ieee->ieee_stats.tx_discards_wrong_sa;
==================
^ permalink raw reply related
* Re: 2.6.17.1: fails to fully get webpage
From: David Miller @ 2006-06-29 3:47 UTC (permalink / raw)
To: cat; +Cc: linux-kernel, netdev
In-Reply-To: <20060629030923.GI2149@zip.com.au>
From: CaT <cat@zip.com.au>
Date: Thu, 29 Jun 2006 13:09:23 +1000
> Yup. Must've. Just tried it now and setting tcp_window_scaling to 0
> makes the site load. Sorry about that. Looks like I'll have to remember
> to make sure that gets set to zero on any servers I wind up having to
> upgrade to 2.6.17 and beyond.
>
> Bugger. :/
You can save yourself that hassle by informing the site admin
of the affected site that they have a firewall that misinterprets
the RFC standard window scaling field of the TCP headers. These
devices assume it is zero because they don't remember the window
scale negotiated at the beginning of the TCP connection.
Your TCP performance will suffer greatly if you disable window
scaling across the board. It means that only a 64K window will
be usable by TCP, and you'll not be able to fill the pipe.
Please don't use a screwdriver to pound in a nail :)
^ permalink raw reply
* Re: FW: + qla3xxx-is-bust.patch added to -mm tree
From: Doug Maxey @ 2006-06-29 3:41 UTC (permalink / raw)
To: Ron Mercer; +Cc: Andrew Morton, netdev, Linux Driver
In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC07176D31@AVEXCH1.qlogic.org>
On Wed, 28 Jun 2006 16:07:22 PDT, "Ron Mercer" wrote:
> >
> > Is the device hotpluggable? If so, this:
> >
> > qdev->index = cards_found;
> >
> > in the probe() handler might do odd things - it'll just keep
> > increasing as the card is removed and re-added.
> >
> > iirc, that's a common problem with net drivers. AFAICT it'll
> > cause only cosmetic oddities here.
> >
> >
>
> Not sure if the device supports hotplug. I'm looking into it. Either
> way, I will be removing qdev->index. It's not needed.
>
Oh indeed it will on System p, the new name for the power series.
Both it and the qla4xxx on a single adapter can (and will) be moved
between partitions, preceded by a hot-unplug in the DLPAR environment.
++doug
^ permalink raw reply
* Re: 2.6.17.1: fails to fully get webpage
From: CaT @ 2006-06-29 3:09 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20060628.194627.74748190.davem@davemloft.net>
On Wed, Jun 28, 2006 at 07:46:27PM -0700, David Miller wrote:
> From: CaT <cat@zip.com.au>
> Date: Thu, 29 Jun 2006 11:59:15 +1000
>
> > Now I found a thread about tcp window scaling affecting the loading of
> > some sites but I fail to load the above site with
> > /proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
> > whilst it works just fine with the /proc entry set to either 7, 6 or 2
> > under 2.6.16.18.
>
> You must have misread those threads. To work around the problem,
> you don't modify tcp_adv_win_scale, instead what you do is set
> tcp_window_scaling to 0.
Yup. Must've. Just tried it now and setting tcp_window_scaling to 0
makes the site load. Sorry about that. Looks like I'll have to remember
to make sure that gets set to zero on any servers I wind up having to
upgrade to 2.6.17 and beyond.
Bugger. :/
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
^ permalink raw reply
* Re: 2.6.17.1: fails to fully get webpage
From: David Miller @ 2006-06-29 2:46 UTC (permalink / raw)
To: cat; +Cc: linux-kernel, netdev
In-Reply-To: <20060629015915.GH2149@zip.com.au>
From: CaT <cat@zip.com.au>
Date: Thu, 29 Jun 2006 11:59:15 +1000
> Now I found a thread about tcp window scaling affecting the loading of
> some sites but I fail to load the above site with
> /proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
> whilst it works just fine with the /proc entry set to either 7, 6 or 2
> under 2.6.16.18.
You must have misread those threads. To work around the problem,
you don't modify tcp_adv_win_scale, instead what you do is set
tcp_window_scaling to 0.
^ permalink raw reply
* [PATCH 2/3] Add support for the Cicada 8201 PHY
From: Kim Phillips @ 2006-06-29 2:13 UTC (permalink / raw)
To: netdev, linuxppc-dev; +Cc: jeff, Andy Fleming
Add support for the Cicada 8201 PHY, a.k.a Vitesse VSC8201. This PHY is present on the MPC8349mITX.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Andy Fleming <afleming@freescale.com>
---
drivers/net/phy/cicada.c | 42 ++++++++++++++++++++++++++++++++++++------
1 files changed, 36 insertions(+), 6 deletions(-)
9834dea86d3620e223584ebc2b04fda4e44092a9
diff --git a/drivers/net/phy/cicada.c b/drivers/net/phy/cicada.c
index 7d8d534..b755c86 100644
--- a/drivers/net/phy/cicada.c
+++ b/drivers/net/phy/cicada.c
@@ -104,7 +104,22 @@ static int cis820x_config_intr(struct ph
return err;
}
-/* Cicada 820x */
+/* Cicada 8201, a.k.a Vitesse VSC8201 */
+static struct phy_driver cis8201_driver = {
+ .phy_id = 0x000fc410,
+ .name = "Cicada Cis8201",
+ .phy_id_mask = 0x000ffff0,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &cis820x_config_init,
+ .config_aneg = &genphy_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &cis820x_ack_interrupt,
+ .config_intr = &cis820x_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+};
+
+/* Cicada 8204 */
static struct phy_driver cis8204_driver = {
.phy_id = 0x000fc440,
.name = "Cicada Cis8204",
@@ -119,15 +134,30 @@ static struct phy_driver cis8204_driver
.driver = { .owner = THIS_MODULE,},
};
-static int __init cis8204_init(void)
+static int __init cicada_init(void)
{
- return phy_driver_register(&cis8204_driver);
+ int ret;
+
+ ret = phy_driver_register(&cis8204_driver);
+ if (ret)
+ goto err1;
+
+ ret = phy_driver_register(&cis8201_driver);
+ if (ret)
+ goto err2;
+ return 0;
+
+err2:
+ phy_driver_unregister(&cis8204_driver);
+err1:
+ return ret;
}
-static void __exit cis8204_exit(void)
+static void __exit cicada_exit(void)
{
phy_driver_unregister(&cis8204_driver);
+ phy_driver_unregister(&cis8201_driver);
}
-module_init(cis8204_init);
-module_exit(cis8204_exit);
+module_init(cicada_init);
+module_exit(cicada_exit);
--
1.2.4
^ permalink raw reply related
* 2.6.17.1: fails to fully get webpage
From: CaT @ 2006-06-29 1:59 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
I had recently upgraded to 2.6.17.1 and tried to go to
http://submit.spam.acma.gov.au/acma_submit.cgi?lang=EN
to report an australian spammer. Unfortunately the loading of the
webpage cuts out at 5472 bytes. I can repeat this each and every time
under 2.6.17.1 with
( echo 'get /acma_submit.cgi?lang=EN http/1.1'; echo 'Host: submit.spam.acma.gov.au'; echo ) | nc submit.spam.acma.gov.au 80
Under 2.6.16.18 the site works without problems.
Now I found a thread about tcp window scaling affecting the loading of
some sites but I fail to load the above site with
/proc/sys/net/ipv4/tcp_adv_win_scale set to 6 and 2 under 2.6.17.1
whilst it works just fine with the /proc entry set to either 7, 6 or 2
under 2.6.16.18.
I have attached a tcpdump of the transaction under 2.6.17.1 and a copy
of the networking section of the .config. If there's any more info
required I'll do my best to grab it.
--
"To the extent that we overreact, we proffer the terrorists the
greatest tribute."
- High Court Judge Michael Kirby
[-- Attachment #2: wscale --]
[-- Type: text/plain, Size: 1720 bytes --]
16:28:51.829502 IP 192.168.1.93.49140 > 210.193.176.194.80: S 3496794602:3496794
602(0) win 5840 <mss 1460,sackOK,timestamp 4294784053 0,nop,wscale 7>
16:28:51.841919 IP 210.193.176.194.80 > 192.168.1.93.49140: S 4198909797:4198909
797(0) ack 3496794603 win 5792 <mss 1380,sackOK,timestamp 2593750330 4294784053,
nop,wscale 2>
16:28:51.841995 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 1 win 46 <nop,nop,timestamp 4294784065 2593750330>
16:28:51.842111 IP 192.168.1.93.49140 > 210.193.176.194.80: P 1:466(465) ack 1 win 46 <nop,nop,timestamp 4294784065 2593750330>
16:28:51.849376 IP 210.193.176.194.80 > 192.168.1.93.49140: . ack 466 win 1716 <nop,nop,timestamp 2593750332 4294784065>
16:28:52.184832 IP 210.193.176.194.80 > 192.168.1.93.49140: . 1:1369(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.184875 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 1369 win 69 <nop,nop,timestamp 4294784408 2593750416>
16:28:52.187593 IP 210.193.176.194.80 > 192.168.1.93.49140: . 1369:2737(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.187632 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 2737 win 91 <nop,nop,timestamp 4294784411 2593750416>
16:28:52.187801 IP 210.193.176.194.80 > 192.168.1.93.49140: P 2737:4105(1368) ack 466 win 1716 <nop,nop,timestamp 2593750416 4294784065>
16:28:52.187824 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 4105 win 114 <nop,nop,timestamp 4294784411 2593750416>
16:28:52.194277 IP 210.193.176.194.80 > 192.168.1.93.49140: . 4105:5473(1368) ack 466 win 1716 <nop,nop,timestamp 2593750418 4294784408>
16:28:52.194337 IP 192.168.1.93.49140 > 210.193.176.194.80: . ack 5473 win 137 <nop,nop,timestamp 4294784418 2593750418>
[-- Attachment #3: config.net --]
[-- Type: text/plain, Size: 6547 bytes --]
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
CONFIG_NET_KEY=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=y
CONFIG_INET_ESP=y
CONFIG_INET_IPCOMP=y
CONFIG_INET_XFRM_TUNNEL=y
CONFIG_INET_TUNNEL=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_BIC=y
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
CONFIG_NETFILTER_XT_TARGET_NOTRACK=y
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=y
CONFIG_NETFILTER_XT_MATCH_CONNMARK=y
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_DCCP=y
CONFIG_NETFILTER_XT_MATCH_ESP=y
CONFIG_NETFILTER_XT_MATCH_HELPER=y
CONFIG_NETFILTER_XT_MATCH_LENGTH=y
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
CONFIG_NETFILTER_XT_MATCH_REALM=y
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
CONFIG_NETFILTER_XT_MATCH_STRING=y
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=y
# CONFIG_IP_NF_CT_PROTO_SCTP is not set
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_NETBIOS_NS=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_H323=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
# CONFIG_IP_NF_NAT_SNMP_BASIC is not set
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_NAT_H323=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_TTL=y
# CONFIG_IP_NF_TARGET_CLUSTERIP is not set
CONFIG_IP_NF_RAW=y
# CONFIG_IP_NF_ARPTABLES is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set
CONFIG_NET_CLS_ROUTE=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_IEEE80211 is not set
#
# Device Drivers
#
...
#
# Network device support
#
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=y
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_PPP_MPPE=y
CONFIG_PPPOE=y
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_MON is not set
^ permalink raw reply
* Re: FW: + qla3xxx-is-bust.patch added to -mm tree
From: Jeff Garzik @ 2006-06-29 1:37 UTC (permalink / raw)
To: Ron Mercer; +Cc: Andrew Morton, netdev, Linux Driver
In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC07176D31@AVEXCH1.qlogic.org>
Ron Mercer wrote:
>> Is the device hotpluggable? If so, this:
>>
>> qdev->index = cards_found;
>>
>> in the probe() handler might do odd things - it'll just keep
>> increasing as the card is removed and re-added.
>>
>> iirc, that's a common problem with net drivers. AFAICT it'll
>> cause only cosmetic oddities here.
>>
>>
>
> Not sure if the device supports hotplug. I'm looking into it. Either
If its a PCI device, it does... depends more on the bus than the device.
> way, I will be removing qdev->index. It's not needed.
Sounds good.
> I am working on the remaining items that Jeff pointed out when he
> reviewed my driver. I will forward a patch built against what you
> currently have when I'm done.
>
> Now that the driver is in mm tree, is there anything I need to do to get
> it into Linus' tree?
Fix the stuff I pointed out...
Jeff
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-29 0:25 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <44A2FA66.5070303@fr.ibm.com>
Daniel Lezcano <dlezcano@fr.ibm.com> writes:
> Andrey Savochkin wrote:
>
>> Ok, fine.
>> Now I'm working on socket code.
>> We still have a question about implicit vs explicit function parameters.
>> This question becomes more important for sockets: if we want to allow to use
>> sockets belonging to namespaces other than the current one, we need to do
>> something about it.
>> One possible option to resolve this question is to show 2 relatively short
>> patches just introducing namespaces for sockets in 2 ways: with explicit
>> function parameters and using implicit current context.
>> Then people can compare them and vote.
>> Do you think it's worth the effort?
>>
>
> The attached patch can have some part interesting for you for the socket
> tagging. It is in the IPV4 isolation (part 5/6). With this and the private
> routing table you will probably have a good IPV4 isolation.
> This patch partially isolates ipv4 by adding the network namespace
> structure in the structure sock, bind bucket and skbuf.
Ugh. skbuf sounds very wrong. Per packet overhead?
> When a socket
> is created, the pointer to the network namespace is stored in the
> struct sock and the socket belongs to the namespace by this way. That
> allows to identify sockets related to a namespace for lookup and
> procfs.
>
> The lookup is extended with a network namespace pointer, in
> order to identify listen points binded to the same port. That allows
> to have several applications binded to INADDR_ANY:port in different
> network namespace without conflicting. The bind is checked against
> port and network namespace.
Yes. If we don't duplicate the hash table we need to extend the lookup.
> When an outgoing packet has the loopback destination addres, the
> skbuff is filled with the network namespace. So the loopback packets
> never go outside the namespace. This approach facilitate the migration
> of loopback because identification is done by network namespace and
> not by address. The loopback has been benchmarked by tbench and the
> overhead is roughly 1.5 %
Ugh. 1.5% is noticeable.
I think it is cheaper to have one loopback device per namespace.
Which removes the need for a skbuff tag.
Eric
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: Eric W. Biederman @ 2006-06-29 0:19 UTC (permalink / raw)
To: James Morris
Cc: Daniel Lezcano, Andrey Savochkin, Eric W. Biederman, linux-kernel,
netdev, serue, haveblue, clg, Andrew Morton, dev, herbert, devel,
sam, Al Viro, Alexey Kuznetsov
In-Reply-To: <Pine.LNX.4.64.0606281851300.16528@d.namei>
James Morris <jmorris@namei.org> writes:
> On Wed, 28 Jun 2006, Daniel Lezcano wrote:
>
>> The attached patch can have some part interesting for you for the socket
>> tagging. It is in the IPV4 isolation (part 5/6). With this and the private
>> routing table you will probably have a good IPV4 isolation.
>
> Please send patches inline, do not attach them.
>
> (Perhaps we should have a filter on vger which drops emails with
> attachements).
>
> All of this needs to be done in a way where it can be entirely disabled at
> compile time, so there is zero overhead for people who don't want
> network namespaces.
I agree with the principle of no overhead.
The goal is an implementation that has no measurable overhead when
there is only one network namespace.
If that goal is achieved and you can compile in the network namespace
code and not measure overhead there should be no need for a compile
time option.
Eric
^ permalink raw reply
* [PATCH] bcm43xx-softmac: Fix an off-by-one condition in handle_irq_noise
From: Larry Finger @ 2006-06-29 0:11 UTC (permalink / raw)
To: John Linville, netdev
An assert statement near the start of handle_irq_noise in the softmac version of bcm43xx_main.c is
there to protect against out of bound addressing using variable bcm->noisecalc.nr_samples. The
arrays in question have a dimension of 8, thus the value must be < 8.
Signed-Off-By: Larry.Finger <Larry.Finger@lwfinger.net>
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
index af97755..c154be0 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -1547,7 +1547,7 @@ static void handle_irq_noise(struct bcm4
goto generate_new;
/* Get the noise samples. */
- assert(bcm->noisecalc.nr_samples <= 8);
+ assert(bcm->noisecalc.nr_samples < 8);
i = bcm->noisecalc.nr_samples;
noise[0] = limit_value(noise[0], 0, ARRAY_SIZE(radio->nrssi_lt) - 1);
noise[1] = limit_value(noise[1], 0, ARRAY_SIZE(radio->nrssi_lt) - 1);
Larry
^ permalink raw reply related
* Re: 2.6.17-mm3 -- NULL pointer dereference at virtual address 00000020 / EIP is at prism2_registers_proc_read+0x22/0x2ff [hostap_cs]
From: Andrew Morton @ 2006-06-29 0:08 UTC (permalink / raw)
To: Miles Lane; +Cc: linux-kernel, John W. Linville, netdev
In-Reply-To: <a44ae5cd0606281634o45795e89y8789e670448f52e3@mail.gmail.com>
"Miles Lane" <miles.lane@gmail.com> wrote:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual
> address 00000020
> printing eip:
> f8d21f6e
> *pde = 00000000
> Oops: 0000 [#1]
> 4K_STACKS PREEMPT
> last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_setspeed
> Modules linked in: sg sd_mod usb_storage libusual pcnet_cs 8390
> aha152x_cs scsi_transport_spi ohci_hcd hostap_cs hostap binfmt_misc
> i915 drm ipv6 speedstep_centrino cpufreq_powersave cpufreq_performance
> cpufreq_conservative video thermal button nls_ascii nls_cp437 vfat fat
> nls_utf8 ntfs nls_base md_mod sr_mod sbp2 scsi_mod parport_pc lp
> parport snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss
> snd_mixer_oss snd_pcm snd_timer ehci_hcd pcspkr evdev iTCO_wdt sdhci
> mmc_core uhci_hcd usbcore psmouse snd ipw2200 rtc intel_agp agpgart
> ohci1394 ieee1394 soundcore snd_page_alloc 8139too
> CPU: 0
> EIP: 0060:[<f8d21f6e>] Not tainted VLI
> EFLAGS: 00210246 (2.6.17-mm3miles #15)
> EIP is at prism2_registers_proc_read+0x22/0x2ff [hostap_cs]
> eax: 00000000 ebx: f8d21f4c ecx: 00000000 edx: e884ef64
> esi: d5bd04e4 edi: db8ce000 ebp: e884ef38 esp: e884ef2c
> ds: 007b es: 007b ss: 0068
> Process cat (pid: 2219, ti=e884e000 task=cdd3e870 task.ti=e884e000)
> Stack: f8d21f4c 00000400 db8ce000 e884ef78 c1090c8b 00000400 e884ef68 d5bd04e4
> 00000400 0806c000 cac1123c 00000000 00000400 f7b6b838 00000000 00000000
> dc8ff844 c1090b8c 0806c000 e884ef94 c105fe38 e884efa0 00000400 dc8ff844
> Call Trace:
> [<c1090c8b>] proc_file_read+0xff/0x218
> [<c105fe38>] vfs_read+0xa9/0x158
> [<c1060207>] sys_read+0x3b/0x60
> [<c1002d6d>] sysenter_past_esp+0x56/0x8d
> Code: c8 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c7 8b 75 10 85
> c9 74 10 8b 45 0c c7 00 01 00 00 00 31 c0 e9 d8 02 00 00 8b 46 14 <8b>
> 50 20 66 ed 0f b7 c0 50 68 03 4a d2 f8 57 e8 42 46 3d c8 8d
> EIP: [<f8d21f6e>] prism2_registers_proc_read+0x22/0x2ff [hostap_cs]
> SS:ESP 0068:e884ef2c
local_info_t.dev is NULL in prism2_registers_proc_read().
Can you please provide a step-by-step means by which others can reproduce
this?
^ permalink raw reply
* RE: TOE, etc.
From: Caitlin Bestler @ 2006-06-28 23:54 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, swise, herbert, netdev
Jeff Garzik wrote:
> Caitlin Bestler wrote:
>> Jeff Garzik wrote:
>>> Caitlin Bestler wrote:
>>>> But hardware iSCSI implementations, which already exist, do not
>>>> work through normal sockets.
>
>>> No, they work through normal SCSI stack...
>
>> Correct.
>>
>> But they then interface to the network using none of the network
>> stack. The normal SCSI stack does not control that it any way.
>
> Correct. And the network stack is completely unaware of
> whatever IP addresses, ARP tables, routing tables, etc. it is using.
>
>
>> NFS over RDMA is part of the file system. That doesn't change the
>> fact that it's use of IP Addresses needs to be co-ordinated with the
>> network stack, and indeed that address based authentication
>> *assumes* that this is the case. (and yes, there are preferable
>> means of authentication, but authenticating based on IP address is
>> already supported).
>
> Sounds quite broken to me.
>
>
>> But back on the main point, if implementing SCSI services over a
>> TCP connection is acceptable even though it does not use a kernel
>> socket, why would it not be acceptable to implement RDMA services
>> over a TCP connection without using a kernel socket?
>
> Because SCSI doesn't force nasty hooks into the net stack to
> allow for
> sharing of resources with a proprietary black box of unknown quality.
>
> Jeff
RDMA can also solve all of these problems on its own. Complete with
giving the network administrator *no* conventional controls over the
IP address being used for RDMA services.
That means no standard ability to monitor connections, no standard
ability to control which connections are made with whom.
That is better?
You seem to be practically demanding that RDMA build an entire
parallel stack.
Worse, that *each* RDMA vendor build an entire parallel stack.
Open source being what it is, that is not terribly difficult.
But exactly how does this benefit Linux users?
The proposed subscriptions are not about sharing *resources*, they
share *information* with device drivers. The quality of each
RDMA device driver will be just as known as for a SCSI driver,
an InfiniBand HCA driver, a graphics driver or a plain Ethernet
driver.
^ permalink raw reply
* Re: TOE, etc.
From: Jeff Garzik @ 2006-06-28 23:43 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David Miller, swise, herbert, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F15F5BA4@NT-SJCA-0751.brcm.ad.broadcom.com>
Caitlin Bestler wrote:
> Jeff Garzik wrote:
>> Caitlin Bestler wrote:
>>> But hardware iSCSI implementations, which already exist, do not work
>>> through normal sockets.
>> No, they work through normal SCSI stack...
> Correct.
>
> But they then interface to the network using none of the network stack.
> The normal SCSI stack does not control that it any way.
Correct. And the network stack is completely unaware of whatever IP
addresses, ARP tables, routing tables, etc. it is using.
> NFS over RDMA is part of the file system. That doesn't change the fact
> that it's use of IP Addresses needs to be co-ordinated with the network
> stack, and indeed that address based authentication *assumes* that this
> is the case. (and yes, there are preferable means of authentication, but
> authenticating based on IP address is already supported).
Sounds quite broken to me.
> But back on the main point, if implementing SCSI services over a
> TCP connection is acceptable even though it does not use a kernel
> socket, why would it not be acceptable to implement RDMA services
> over a TCP connection without using a kernel socket?
Because SCSI doesn't force nasty hooks into the net stack to allow for
sharing of resources with a proprietary black box of unknown quality.
Jeff
^ permalink raw reply
* Re: FW: + qla3xxx-is-bust.patch added to -mm tree
From: Andrew Morton @ 2006-06-28 23:24 UTC (permalink / raw)
To: Ron Mercer; +Cc: netdev, Linux-Driver
In-Reply-To: <0BB3E5E7462EEA4295BC02D49691DC07176D31@AVEXCH1.qlogic.org>
"Ron Mercer" <ron.mercer@qlogic.com> wrote:
>
> >
> > Is the device hotpluggable? If so, this:
> >
> > qdev->index = cards_found;
> >
> > in the probe() handler might do odd things - it'll just keep
> > increasing as the card is removed and re-added.
> >
> > iirc, that's a common problem with net drivers. AFAICT it'll
> > cause only cosmetic oddities here.
> >
> >
>
> Not sure if the device supports hotplug. I'm looking into it. Either
> way, I will be removing qdev->index. It's not needed.
>
> I am working on the remaining items that Jeff pointed out when he
> reviewed my driver. I will forward a patch built against what you
> currently have when I'm done.
OK.
> Now that the driver is in mm tree, is there anything I need to do to get
> it into Linus' tree?
It should go via Jeff. I added it to -mm just to get it a bit of
attention, more reviewers, extra compile coverage testing, etc.
If you want to consider the patch in -mm to be the reference copy then
that's fine. You should do maintenance work against that patch and I'll
add it to the patches which I send to Jeff on Thursdays until he merges it
or rejects it.
^ permalink raw reply
* RE: FW: + qla3xxx-is-bust.patch added to -mm tree
From: Ron Mercer @ 2006-06-28 23:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Linux Driver
>
> Is the device hotpluggable? If so, this:
>
> qdev->index = cards_found;
>
> in the probe() handler might do odd things - it'll just keep
> increasing as the card is removed and re-added.
>
> iirc, that's a common problem with net drivers. AFAICT it'll
> cause only cosmetic oddities here.
>
>
Not sure if the device supports hotplug. I'm looking into it. Either
way, I will be removing qdev->index. It's not needed.
I am working on the remaining items that Jeff pointed out when he
reviewed my driver. I will forward a patch built against what you
currently have when I'm done.
Now that the driver is in mm tree, is there anything I need to do to get
it into Linus' tree?
^ permalink raw reply
* Re: Network namespaces a path to mergable code.
From: James Morris @ 2006-06-28 22:54 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Andrey Savochkin, Eric W. Biederman, linux-kernel, netdev, serue,
haveblue, clg, Andrew Morton, dev, herbert, devel, sam, Al Viro,
Alexey Kuznetsov
In-Reply-To: <44A2FA66.5070303@fr.ibm.com>
On Wed, 28 Jun 2006, Daniel Lezcano wrote:
> The attached patch can have some part interesting for you for the socket
> tagging. It is in the IPV4 isolation (part 5/6). With this and the private
> routing table you will probably have a good IPV4 isolation.
Please send patches inline, do not attach them.
(Perhaps we should have a filter on vger which drops emails with
attachements).
All of this needs to be done in a way where it can be entirely disabled at
compile time, so there is zero overhead for people who don't want
network namespaces.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] [IrDA] MCS7780 usb_driver struct should be static
From: Samuel Ortiz @ 2006-06-29 5:12 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, irda-users, bunk
Hi Dave,
This patch makes a needlessly global struct static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Samuel Ortiz <samuel@sortiz.org>
---
drivers/net/irda/mcs7780.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/irda/mcs7780.c b/drivers/net/irda/mcs7780.c
index 754297f..47f6f64 100644
--- a/drivers/net/irda/mcs7780.c
+++ b/drivers/net/irda/mcs7780.c
@@ -101,7 +101,7 @@ static int transceiver_type = MCS_TSC_VI
module_param(transceiver_type, int, 0444);
MODULE_PARM_DESC(transceiver_type, "IR transceiver type, see mcs7780.h.");
-struct usb_driver mcs_driver = {
+static struct usb_driver mcs_driver = {
.name = "mcs7780",
.probe = mcs_probe,
.disconnect = mcs_disconnect,
--
1.4.0
^ permalink raw reply related
* Re: Network namespaces a path to mergable code.
From: Daniel Lezcano @ 2006-06-28 21:53 UTC (permalink / raw)
To: Andrey Savochkin
Cc: Eric W. Biederman, linux-kernel, netdev, serue, haveblue, clg,
Andrew Morton, dev, herbert, devel, sam, viro, Alexey Kuznetsov
In-Reply-To: <20060628150605.A29274@castle.nmd.msu.ru>
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
Andrey Savochkin wrote:
> Ok, fine.
> Now I'm working on socket code.
>
> We still have a question about implicit vs explicit function parameters.
> This question becomes more important for sockets: if we want to allow to use
> sockets belonging to namespaces other than the current one, we need to do
> something about it.
>
> One possible option to resolve this question is to show 2 relatively short
> patches just introducing namespaces for sockets in 2 ways: with explicit
> function parameters and using implicit current context.
> Then people can compare them and vote.
> Do you think it's worth the effort?
>
The attached patch can have some part interesting for you for the socket
tagging. It is in the IPV4 isolation (part 5/6). With this and the
private routing table you will probably have a good IPV4 isolation.
[-- Attachment #2: inet_isolation.patch --]
[-- Type: text/x-patch, Size: 15640 bytes --]
This patch partially isolates ipv4 by adding the network namespace
structure in the structure sock, bind bucket and skbuf. When a socket
is created, the pointer to the network namespace is stored in the
struct sock and the socket belongs to the namespace by this way. That
allows to identify sockets related to a namespace for lookup and
procfs.
The lookup is extended with a network namespace pointer, in
order to identify listen points binded to the same port. That allows
to have several applications binded to INADDR_ANY:port in different
network namespace without conflicting. The bind is checked against
port and network namespace.
When an outgoing packet has the loopback destination addres, the
skbuff is filled with the network namespace. So the loopback packets
never go outside the namespace. This approach facilitate the migration
of loopback because identification is done by network namespace and
not by address. The loopback has been benchmarked by tbench and the
overhead is roughly 1.5 %
Replace-Subject: [Network namespace] ipv4 isolation
Signed-off-by: Daniel Lezcano <dlezcano@fr.ibm.com>
--
include/linux/skbuff.h | 2 ++
include/net/inet_hashtables.h | 34 ++++++++++++++++++++++++----------
include/net/inet_timewait_sock.h | 1 +
include/net/sock.h | 4 ++++
net/dccp/ipv4.c | 7 ++++---
net/ipv4/af_inet.c | 2 ++
net/ipv4/inet_connection_sock.c | 3 ++-
net/ipv4/inet_diag.c | 3 ++-
net/ipv4/inet_hashtables.c | 6 +++++-
net/ipv4/inet_timewait_sock.c | 1 +
net/ipv4/ip_output.c | 4 ++++
net/ipv4/tcp_ipv4.c | 25 ++++++++++++++++---------
net/ipv4/udp.c | 7 +++++--
13 files changed, 72 insertions(+), 27 deletions(-)
Index: 2.6-mm/include/linux/skbuff.h
===================================================================
--- 2.6-mm.orig/include/linux/skbuff.h
+++ 2.6-mm/include/linux/skbuff.h
@@ -27,6 +27,7 @@
#include <linux/poll.h>
#include <linux/net.h>
#include <linux/textsearch.h>
+#include <linux/net_ns.h>
#include <net/checksum.h>
#include <linux/dmaengine.h>
@@ -301,6 +302,7 @@
*data,
*tail,
*end;
+ struct net_namespace *net_ns;
};
#ifdef __KERNEL__
Index: 2.6-mm/include/net/inet_hashtables.h
===================================================================
--- 2.6-mm.orig/include/net/inet_hashtables.h
+++ 2.6-mm/include/net/inet_hashtables.h
@@ -23,6 +23,8 @@
#include <linux/spinlock.h>
#include <linux/types.h>
#include <linux/wait.h>
+#include <linux/in.h>
+#include <linux/net_ns.h>
#include <net/inet_connection_sock.h>
#include <net/inet_sock.h>
@@ -78,6 +80,7 @@
signed short fastreuse;
struct hlist_node node;
struct hlist_head owners;
+ struct net_namespace *net_ns;
};
#define inet_bind_bucket_for_each(tb, node, head) \
@@ -274,13 +277,15 @@
extern struct sock *__inet_lookup_listener(const struct hlist_head *head,
const u32 daddr,
const unsigned short hnum,
- const int dif);
+ const int dif,
+ const struct net_namespace *net_ns);
/* Optimize the common listener case. */
static inline struct sock *
inet_lookup_listener(struct inet_hashinfo *hashinfo,
const u32 daddr,
- const unsigned short hnum, const int dif)
+ const unsigned short hnum, const int dif,
+ const struct net_namespace *net_ns)
{
struct sock *sk = NULL;
const struct hlist_head *head;
@@ -294,8 +299,9 @@
(!inet->rcv_saddr || inet->rcv_saddr == daddr) &&
(sk->sk_family == PF_INET || !ipv6_only_sock(sk)) &&
!sk->sk_bound_dev_if)
- goto sherry_cache;
- sk = __inet_lookup_listener(head, daddr, hnum, dif);
+ if (sk->sk_net_ns == net_ns && LOOPBACK(daddr))
+ goto sherry_cache;
+ sk = __inet_lookup_listener(head, daddr, hnum, dif, net_ns);
}
if (sk) {
sherry_cache:
@@ -358,7 +364,8 @@
__inet_lookup_established(struct inet_hashinfo *hashinfo,
const u32 saddr, const u16 sport,
const u32 daddr, const u16 hnum,
- const int dif)
+ const int dif,
+ const struct net_namespace *net_ns)
{
INET_ADDR_COOKIE(acookie, saddr, daddr)
const __u32 ports = INET_COMBINED_PORTS(sport, hnum);
@@ -373,12 +380,16 @@
prefetch(head->chain.first);
read_lock(&head->lock);
sk_for_each(sk, node, &head->chain) {
+ if (sk->sk_net_ns != net_ns && LOOPBACK(daddr))
+ continue;
if (INET_MATCH(sk, hash, acookie, saddr, daddr, ports, dif))
goto hit; /* You sunk my battleship! */
}
/* Must check for a TIME_WAIT'er before going to listener hash. */
sk_for_each(sk, node, &(head + hashinfo->ehash_size)->chain) {
+ if (sk->sk_net_ns != net_ns && LOOPBACK(daddr))
+ continue;
if (INET_TW_MATCH(sk, hash, acookie, saddr, daddr, ports, dif))
goto hit;
}
@@ -394,22 +405,25 @@
static inline struct sock *__inet_lookup(struct inet_hashinfo *hashinfo,
const u32 saddr, const u16 sport,
const u32 daddr, const u16 hnum,
- const int dif)
+ const int dif,
+ const struct net_namespace *net_ns)
{
struct sock *sk = __inet_lookup_established(hashinfo, saddr, sport, daddr,
- hnum, dif);
- return sk ? : inet_lookup_listener(hashinfo, daddr, hnum, dif);
+ hnum, dif, net_ns);
+ return sk ? : inet_lookup_listener(hashinfo, daddr, hnum, dif, net_ns);
}
static inline struct sock *inet_lookup(struct inet_hashinfo *hashinfo,
const u32 saddr, const u16 sport,
const u32 daddr, const u16 dport,
- const int dif)
+ const int dif,
+ const struct net_namespace *net_ns)
{
struct sock *sk;
local_bh_disable();
- sk = __inet_lookup(hashinfo, saddr, sport, daddr, ntohs(dport), dif);
+ sk = __inet_lookup(hashinfo, saddr, sport, daddr, ntohs(dport),
+ dif, net_ns);
local_bh_enable();
return sk;
Index: 2.6-mm/include/net/inet_timewait_sock.h
===================================================================
--- 2.6-mm.orig/include/net/inet_timewait_sock.h
+++ 2.6-mm/include/net/inet_timewait_sock.h
@@ -115,6 +115,7 @@
#define tw_refcnt __tw_common.skc_refcnt
#define tw_hash __tw_common.skc_hash
#define tw_prot __tw_common.skc_prot
+#define tw_net_ns __tw_common.skc_net_ns
volatile unsigned char tw_substate;
/* 3 bits hole, try to pack */
unsigned char tw_rcv_wscale;
Index: 2.6-mm/include/net/sock.h
===================================================================
--- 2.6-mm.orig/include/net/sock.h
+++ 2.6-mm/include/net/sock.h
@@ -47,6 +47,7 @@
#include <linux/netdevice.h>
#include <linux/skbuff.h> /* struct sk_buff */
#include <linux/security.h>
+#include <linux/net_ns.h>
#include <linux/filter.h>
@@ -94,6 +95,7 @@
* @skc_refcnt: reference count
* @skc_hash: hash value used with various protocol lookup tables
* @skc_prot: protocol handlers inside a network family
+ * @skc_net_ns: network namespace owning the socket
*
* This is the minimal network layer representation of sockets, the header
* for struct sock and struct inet_timewait_sock.
@@ -108,6 +110,7 @@
atomic_t skc_refcnt;
unsigned int skc_hash;
struct proto *skc_prot;
+ struct net_namespace *skc_net_ns;
};
/**
@@ -183,6 +186,7 @@
#define sk_refcnt __sk_common.skc_refcnt
#define sk_hash __sk_common.skc_hash
#define sk_prot __sk_common.skc_prot
+#define sk_net_ns __sk_common.skc_net_ns
unsigned char sk_shutdown : 2,
sk_no_check : 2,
sk_userlocks : 4;
Index: 2.6-mm/net/dccp/ipv4.c
===================================================================
--- 2.6-mm.orig/net/dccp/ipv4.c
+++ 2.6-mm/net/dccp/ipv4.c
@@ -308,7 +308,8 @@
}
sk = inet_lookup(&dccp_hashinfo, iph->daddr, dh->dccph_dport,
- iph->saddr, dh->dccph_sport, inet_iif(skb));
+ iph->saddr, dh->dccph_sport, inet_iif(skb),
+ skb->net_ns);
if (sk == NULL) {
ICMP_INC_STATS_BH(ICMP_MIB_INERRORS);
return;
@@ -610,7 +611,7 @@
nsk = __inet_lookup_established(&dccp_hashinfo,
iph->saddr, dh->dccph_sport,
iph->daddr, ntohs(dh->dccph_dport),
- inet_iif(skb));
+ inet_iif(skb), skb->net_ns);
if (nsk != NULL) {
if (nsk->sk_state != DCCP_TIME_WAIT) {
bh_lock_sock(nsk);
@@ -924,7 +925,7 @@
sk = __inet_lookup(&dccp_hashinfo,
skb->nh.iph->saddr, dh->dccph_sport,
skb->nh.iph->daddr, ntohs(dh->dccph_dport),
- inet_iif(skb));
+ inet_iif(skb), skb->net_ns);
/*
* Step 2:
Index: 2.6-mm/net/ipv4/af_inet.c
===================================================================
--- 2.6-mm.orig/net/ipv4/af_inet.c
+++ 2.6-mm/net/ipv4/af_inet.c
@@ -325,6 +325,7 @@
sk->sk_family = PF_INET;
sk->sk_protocol = protocol;
sk->sk_backlog_rcv = sk->sk_prot->backlog_rcv;
+ sk->sk_net_ns = net_ns();
inet->uc_ttl = -1;
inet->mc_loop = 1;
@@ -616,6 +617,7 @@
sock_graft(sk2, newsock);
+ sk2->sk_net_ns = net_ns();
newsock->state = SS_CONNECTED;
err = 0;
release_sock(sk2);
Index: 2.6-mm/net/ipv4/inet_connection_sock.c
===================================================================
--- 2.6-mm.orig/net/ipv4/inet_connection_sock.c
+++ 2.6-mm/net/ipv4/inet_connection_sock.c
@@ -116,7 +116,7 @@
head = &hashinfo->bhash[inet_bhashfn(snum, hashinfo->bhash_size)];
spin_lock(&head->lock);
inet_bind_bucket_for_each(tb, node, &head->chain)
- if (tb->port == snum)
+ if (tb->port == snum && tb->net_ns == net_ns())
goto tb_found;
}
tb = NULL;
@@ -146,6 +146,7 @@
} else if (tb->fastreuse &&
(!sk->sk_reuse || sk->sk_state == TCP_LISTEN))
tb->fastreuse = 0;
+ tb->net_ns = net_ns();
success:
if (!inet_csk(sk)->icsk_bind_hash)
inet_bind_hash(sk, tb, snum);
Index: 2.6-mm/net/ipv4/inet_diag.c
===================================================================
--- 2.6-mm.orig/net/ipv4/inet_diag.c
+++ 2.6-mm/net/ipv4/inet_diag.c
@@ -241,7 +241,8 @@
if (req->idiag_family == AF_INET) {
sk = inet_lookup(hashinfo, req->id.idiag_dst[0],
req->id.idiag_dport, req->id.idiag_src[0],
- req->id.idiag_sport, req->id.idiag_if);
+ req->id.idiag_sport, req->id.idiag_if,
+ in_skb->net_ns);
}
#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
else if (req->idiag_family == AF_INET6) {
Index: 2.6-mm/net/ipv4/inet_hashtables.c
===================================================================
--- 2.6-mm.orig/net/ipv4/inet_hashtables.c
+++ 2.6-mm/net/ipv4/inet_hashtables.c
@@ -126,7 +126,8 @@
* wildcarded during the search since they can never be otherwise.
*/
struct sock *__inet_lookup_listener(const struct hlist_head *head, const u32 daddr,
- const unsigned short hnum, const int dif)
+ const unsigned short hnum, const int dif,
+ const struct net_namespace *net_ns)
{
struct sock *result = NULL, *sk;
const struct hlist_node *node;
@@ -139,6 +140,9 @@
const __u32 rcv_saddr = inet->rcv_saddr;
int score = sk->sk_family == PF_INET ? 1 : 0;
+ if (sk->sk_net_ns != net_ns && LOOPBACK(daddr))
+ continue;
+
if (rcv_saddr) {
if (rcv_saddr != daddr)
continue;
Index: 2.6-mm/net/ipv4/inet_timewait_sock.c
===================================================================
--- 2.6-mm.orig/net/ipv4/inet_timewait_sock.c
+++ 2.6-mm/net/ipv4/inet_timewait_sock.c
@@ -110,6 +110,7 @@
tw->tw_hash = sk->sk_hash;
tw->tw_ipv6only = 0;
tw->tw_prot = sk->sk_prot_creator;
+ tw->tw_net_ns = sk->sk_net_ns;
atomic_set(&tw->tw_refcnt, 1);
inet_twsk_dead_node_init(tw);
__module_get(tw->tw_prot->owner);
Index: 2.6-mm/net/ipv4/ip_output.c
===================================================================
--- 2.6-mm.orig/net/ipv4/ip_output.c
+++ 2.6-mm/net/ipv4/ip_output.c
@@ -284,6 +284,10 @@
skb->dev = dev;
skb->protocol = htons(ETH_P_IP);
+ if ((skb->nh.iph->protocol == IPPROTO_TCP ||
+ skb->nh.iph->protocol == IPPROTO_UDP) &&
+ LOOPBACK(skb->nh.iph->daddr))
+ skb->net_ns = skb->sk->sk_net_ns;
return NF_HOOK_COND(PF_INET, NF_IP_POST_ROUTING, skb, NULL, dev,
ip_finish_output,
Index: 2.6-mm/net/ipv4/tcp_ipv4.c
===================================================================
--- 2.6-mm.orig/net/ipv4/tcp_ipv4.c
+++ 2.6-mm/net/ipv4/tcp_ipv4.c
@@ -349,7 +349,7 @@
}
sk = inet_lookup(&tcp_hashinfo, iph->daddr, th->dest, iph->saddr,
- th->source, inet_iif(skb));
+ th->source, inet_iif(skb), skb->net_ns);
if (!sk) {
ICMP_INC_STATS_BH(ICMP_MIB_INERRORS);
return;
@@ -933,7 +933,8 @@
nsk = __inet_lookup_established(&tcp_hashinfo, skb->nh.iph->saddr,
th->source, skb->nh.iph->daddr,
- ntohs(th->dest), inet_iif(skb));
+ ntohs(th->dest), inet_iif(skb),
+ skb->net_ns);
if (nsk) {
if (nsk->sk_state != TCP_TIME_WAIT) {
@@ -1071,7 +1072,7 @@
sk = __inet_lookup(&tcp_hashinfo, skb->nh.iph->saddr, th->source,
skb->nh.iph->daddr, ntohs(th->dest),
- inet_iif(skb));
+ inet_iif(skb), skb->net_ns);
if (!sk)
goto no_tcp_socket;
@@ -1149,7 +1150,8 @@
struct sock *sk2 = inet_lookup_listener(&tcp_hashinfo,
skb->nh.iph->daddr,
ntohs(th->dest),
- inet_iif(skb));
+ inet_iif(skb),
+ skb->net_ns);
if (sk2) {
inet_twsk_deschedule((struct inet_timewait_sock *)sk,
&tcp_death_row);
@@ -1395,7 +1397,8 @@
}
get_sk:
sk_for_each_from(sk, node) {
- if (sk->sk_family == st->family) {
+ if (sk->sk_family == st->family &&
+ sk->sk_net_ns == net_ns()) {
cur = sk;
goto out;
}
@@ -1446,7 +1449,8 @@
read_lock(&tcp_hashinfo.ehash[st->bucket].lock);
sk_for_each(sk, node, &tcp_hashinfo.ehash[st->bucket].chain) {
- if (sk->sk_family != st->family) {
+ if (sk->sk_family != st->family ||
+ sk->sk_net_ns != net_ns()) {
continue;
}
rc = sk;
@@ -1455,7 +1459,8 @@
st->state = TCP_SEQ_STATE_TIME_WAIT;
inet_twsk_for_each(tw, node,
&tcp_hashinfo.ehash[st->bucket + tcp_hashinfo.ehash_size].chain) {
- if (tw->tw_family != st->family) {
+ if (tw->tw_family != st->family ||
+ tw->tw_net_ns != net_ns()) {
continue;
}
rc = tw;
@@ -1481,7 +1486,8 @@
tw = cur;
tw = tw_next(tw);
get_tw:
- while (tw && tw->tw_family != st->family) {
+ while (tw && (tw->tw_family != st->family ||
+ tw->tw_net_ns != net_ns())) {
tw = tw_next(tw);
}
if (tw) {
@@ -1505,7 +1511,8 @@
sk = sk_next(sk);
sk_for_each_from(sk, node) {
- if (sk->sk_family == st->family)
+ if (sk->sk_family == st->family &&
+ sk->sk_net_ns == net_ns())
goto found;
}
Index: 2.6-mm/net/ipv4/udp.c
===================================================================
--- 2.6-mm.orig/net/ipv4/udp.c
+++ 2.6-mm/net/ipv4/udp.c
@@ -184,6 +184,7 @@
(!inet2->rcv_saddr ||
!inet->rcv_saddr ||
inet2->rcv_saddr == inet->rcv_saddr) &&
+ sk2->sk_net_ns == sk->sk_net_ns &&
(!sk2->sk_reuse || !sk->sk_reuse))
goto fail;
}
@@ -1404,7 +1405,8 @@
for (state->bucket = 0; state->bucket < UDP_HTABLE_SIZE; ++state->bucket) {
struct hlist_node *node;
sk_for_each(sk, node, &udp_hash[state->bucket]) {
- if (sk->sk_family == state->family)
+ if (sk->sk_family == state->family &&
+ sk->sk_net_ns == net_ns())
goto found;
}
}
@@ -1421,7 +1423,8 @@
sk = sk_next(sk);
try_again:
;
- } while (sk && sk->sk_family != state->family);
+ } while (sk && (sk->sk_family != state->family ||
+ sk->sk_net_ns != net_ns()));
if (!sk && ++state->bucket < UDP_HTABLE_SIZE) {
sk = sk_head(&udp_hash[state->bucket]);
--
^ permalink raw reply
* Re: [PATCH 6/7] net: Add QE UCC Gigabit Ethernet driver
From: Andrew Morton @ 2006-06-28 21:51 UTC (permalink / raw)
To: Li Yang-r58472
Cc: jgarzik, netdev, linuxppc-dev, linux-kernel, Hanjin.Chu, gridish
In-Reply-To: <9FCDBA58F226D911B202000BDBAD467306E04FD7@zch01exm40.ap.freescale.net>
Li Yang-r58472 <LeoLi@freescale.com> wrote:
>
> This is a gigabit Ethernet driver for Freescale QE(QUICC ENGINE) SOC. QE can be found on PowerQUICC II pro family.
>
>
>
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index bdaaad8..ebbb218 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -2189,6 +2189,33 @@ config GFAR_NAPI
> bool "NAPI Support"
> depends on GIANFAR
>
> +config UCC_GETH
> + tristate "Freescale QE UCC GETH"
> + depends on QUICC_ENGINE
Opinions vary, but it can be useful if drivers such as this are compilable
on common architectures (ie: x86). That way, lots of people end up
compiling it and problems (generally simple ones) can be fixed for you.
Plus it's much less likely that someone will break your driver by accident.
Then again, it'll cause people to build a driver which they cannot possibly
use..
> # link order important here
> #
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> new file mode 100644
> index 0000000..a7be2eb
> --- /dev/null
> +++ b/drivers/net/ucc_geth.c
>
> ...
>
> +#include <asm/uaccess.h>
> +#include <asm/irq.h>
> +#include <asm/io.h>
> +#include <asm/immap_qe.h>
> +#include <asm/qe.h>
> +
> +#include <asm/ucc.h>
> +#include <asm/ucc_fast.h>
Well that rather rules out the x86 option.
> +
> +static ucc_geth_info_t ugeth_primary_info = {
> + .uf_info = {
> + .bd_mem_part = MEM_PART_SYSTEM,
> + .brkpt_support = 0,
> + .grant_support = 0,
> + .tsa = 0,
> + .cdp = 0,
> + .cds = 0,
> + .ctsp = 0,
> + .ctss = 0,
> + .tci = 0,
> + .txsy = 0,
> + .rtsm = UCC_FAST_SEND_IDLES_BETWEEN_FRAMES,
> + .revd = 0,
> + .rsyn = 0,
Note that all the `.foo = 0' lines aren't needed.
> + .l2qt = {0, 0, 0, 0, 0, 0, 0, 0},
> + .l3qt = {0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0,
> + 0, 0, 0, 0, 0, 0, 0, 0},
> + .vtagtable = {0, 0, 0, 0, 0, 0, 0, 0},
> + .iphoffset = {0, 0, 0, 0, 0, 0, 0, 0},
In fact I'd be inclined to remove them - the chances of keeping this table
in sync with the actual struct definition seem low.
> +
> +#ifdef DEBUG
> +static void mem_disp(u8 * addr, int size)
> +{
> + u8 *i;
> + int size16Aling = (size >> 4) << 4;
> + int size4Aling = (size >> 2) << 2;
> + int notAlign = 0;
> + if (size % 16)
> + notAlign = 1;
> +
> + for (i = addr; (u32) i < (u32) addr + size16Aling; i += 16)
> + printk("0x%08x: %08x %08x %08x %08x\r\n",
> + (u32) i,
> + *((u32 *) (i)),
> + *((u32 *) (i + 4)),
> + *((u32 *) (i + 8)), *((u32 *) (i + 12)));
> + if (notAlign == 1)
> + printk("0x%08x: ", (u32) i);
> + for (; (u32) i < (u32) addr + size4Aling; i += 4)
> + printk("%08x ", *((u32 *) (i)));
> + for (; (u32) i < (u32) addr + size; i++)
> + printk("%02x", *((u8 *) (i)));
> + if (notAlign == 1)
> + printk("\r\n");
> +}
> +#endif /* DEBUG */
This is very non-64-bit.
> +#ifdef CONFIG_UGETH_FILTERING
> +static void enqueue(struct list_head *node, struct list_head *lh)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + list_add_tail(node, lh);
> + local_irq_restore(flags);
> +}
> +#endif /* CONFIG_UGETH_FILTERING */
And local_irq_save() is very non-SMP (isn't it?)
> +static struct list_head *dequeue(struct list_head *lh)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + if (!list_empty(lh)) {
> + struct list_head *node = lh->next;
> + list_del(node);
> + local_irq_restore(flags);
> + return node;
> + } else {
> + local_irq_restore(flags);
> + return NULL;
> + }
> +}
Unless this really really really never will run on SMP, it'd be better to
use spin_lock_irqsave() here. That's equivalent on !SMP.
> +static struct sk_buff *get_new_skb(ucc_geth_private_t * ugeth, u8 * bd)
Preferred coding style is
static struct sk_buff *get_new_skb(ucc_geth_private_t *ugeth, u8 *bd)
> +{
> + struct sk_buff *skb = NULL;
> + unsigned int timeout = SKB_ALLOC_TIMEOUT;
> +
> + /* We have to allocate the skb, so keep trying till we succeed */
> + while ((!skb) && timeout--)
> + skb =
> + dev_alloc_skb(ugeth->ug_info->uf_info.max_rx_buf_length +
> + UCC_GETH_RX_DATA_BUF_ALIGNMENT);
This is pretty pointless. If the first allocation attempt failed then
for-sure the rest of them will fail too. All it does is waste CPU.
> +
> +static int rx_bd_buffer_set(ucc_geth_private_t * ugeth, u8 rxQ)
> +{
> + u8 *bd;
> + u32 bd_status;
> + struct sk_buff *skb;
> + int i;
> +
> + if (!ugeth) {
> + ugeth_err("%s: No handle passed.", __FUNCTION__);
> + return -EINVAL;
> + }
Presumably, this can't happen. Suggest you remove this code and let the
thing oops if it does happen.
> +static int fill_init_enet_entries(ucc_geth_private_t * ugeth,
> + volatile u32 * p_start,
> + u8 num_entries,
> + u32 thread_size,
> + u32 thread_alignment,
> + qe_risc_allocation_e risc,
> + int skip_page_for_first_entry)
> +{
> + u32 init_enet_offset;
> + u8 i;
> + int snum;
> +
> + if (!ugeth || !ugeth->uccf) {
> + ugeth_err("%s: No handle passed.", __FUNCTION__);
> + return -EINVAL;
> + }
Ditto.
> +#ifdef CONFIG_UGETH_FILTERING
> +static enet_addr_container_t *get_enet_addr_container(void)
> +{
> + enet_addr_container_t *enet_addr_cont;
> +
> + /* allocate memory */
> + enet_addr_cont =
> + (enet_addr_container_t *) kmalloc(sizeof(enet_addr_container_t),
Unneeded typecast.
> +
> +static inline int compare_addr(enet_addr_t * addr1, enet_addr_t * addr2)
> +{
> + return strncmp((char *)addr1, (char *)addr2,
> + ENET_NUM_OCTETS_PER_ADDRESS);
> +}
Shouldn't this use memcmp()? strncmp() will stop at 0x00.
> + mem_disp((u8 *) & ugeth->p_thread_data_tx[i],
> + sizeof(ucc_geth_thread_data_tx_t));
We should have a kernel-wide printk-a-block-of-memory-out library function,
but we don't.
> +static int init_check_frame_length_mode(int length_check,
> + volatile u32 * maccfg2_register)
> +{
> + u32 value = 0;
Unneeded initialisation (lots of places).
> + value = in_be32(maccfg2_register);
> +/* Called every time the controller might need to be made
> + * aware of new link state. The PHY code conveys this
> + * information through variables in the ugeth structure, and this
> + * function converts those variables into the appropriate
> + * register values, and can bring down the device if needed.
> + */
> +#include <linux/mii.h>
This is a funny place to be including a header file. Better to put it at
the top of the .c file.
[remainder skipped - it's a big driver]
^ permalink raw reply
* RE: TOE, etc.
From: Caitlin Bestler @ 2006-06-28 21:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, swise, herbert, netdev
Jeff Garzik wrote:
> Caitlin Bestler wrote:
>> netdev-owner@vger.kernel.org wrote:
>>> From: Steve Wise <swise@opengridcomputing.com>
>>> Date: Wed, 28 Jun 2006 09:54:57 -0500
>>>
>>>> Doesn't iSCSI have this same issue?
>>> Software iSCSI implementations don't have the issue because they go
>>> through the stack using normal sockets and normal device send and
>>> receive.
>>
>> But hardware iSCSI implementations, which already exist, do not work
>> through normal sockets.
>
> No, they work through normal SCSI stack...
>
> Jeff
Correct.
But they then interface to the network using none of the network stack.
The normal SCSI stack does not control that it any way.
NFS over RDMA is part of the file system. That doesn't change the fact
that it's use of IP Addresses needs to be co-ordinated with the network
stack, and indeed that address based authentication *assumes* that this
is the case. (and yes, there are preferable means of authentication, but
authenticating based on IP address is already supported).
But back on the main point, if implementing SCSI services over a
TCP connection is acceptable even though it does not use a kernel
socket, why would it not be acceptable to implement RDMA services
over a TCP connection without using a kernel socket?
^ permalink raw reply
* Re: TOE, etc.
From: Jeff Garzik @ 2006-06-28 21:10 UTC (permalink / raw)
To: Caitlin Bestler; +Cc: David Miller, swise, herbert, netdev
In-Reply-To: <54AD0F12E08D1541B826BE97C98F99F15F5B6D@NT-SJCA-0751.brcm.ad.broadcom.com>
Caitlin Bestler wrote:
> netdev-owner@vger.kernel.org wrote:
>> From: Steve Wise <swise@opengridcomputing.com>
>> Date: Wed, 28 Jun 2006 09:54:57 -0500
>>
>>> Doesn't iSCSI have this same issue?
>> Software iSCSI implementations don't have the issue because
>> they go through the stack using normal sockets and normal
>> device send and receive.
>
> But hardware iSCSI implementations, which already exist,
> do not work through normal sockets.
No, they work through normal SCSI stack...
Jeff
^ permalink raw reply
* Re: [PATCH, RFT] bcm43xx: AccessPoint mode
From: Francois Barre @ 2006-06-28 19:50 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko
In-Reply-To: <200606282139.41441.mb@bu3sch.de>
>
> Well, I doubt it is a bcm43xx issue. But maybe. Not sure.
>
> Do you run some QoS stuff? Some other quota stuff?
>
Yes, a special QoS rule that cuts off connections from devices that do
not use a GPL driver.
Long life to the penguin !
Soon, my HiFi will cut off the whole drum section of the DRM songs
I'll ask it to play, and I'm thinking about how to teach my oven not
to bake GM Food :-p.
More seriously, no, I do not have any QoS nor quota service running.
Instead, I was more thinking about a beacon at high rates, but I do not have
enough 802.11 knowledge to know what is advertised during connection...
Maybe the netdev guys would have a clue, a tool, or a bright idea ?
^ permalink raw reply
* Re: [PATCH, RFT] bcm43xx: AccessPoint mode
From: Michael Buesch @ 2006-06-28 19:39 UTC (permalink / raw)
To: Francois Barre; +Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko
In-Reply-To: <fd8d0180606281227m309b0fcr94bc42c4c5247000@mail.gmail.com>
On Wednesday 28 June 2006 21:27, Francois Barre wrote:
> Hi all,
>
> Sorry for answering years after the patch post, I didn't have time to
> test this take2 patch before. I had a first look at it a couple of
> days ago, but... you know, that was not my day.
>
> > Well, it does not work 100%, but at least it's very promising.
> > We are able to create a bssid and correctly send beacon frames out.
> [...]
>
> For my very own situation, that is :
> - Apple Mini with a BCM 4306 (BigEndian)
> - Linux/Win32 boxes with USB and PCMCIA wifi cards (mostly 802.11b usb
> at the moment)
>
> Current status is this one :
> - master mode functionnal
> - dhcp serving, good uptime
> - no encryption, WEP or WPA of any kind tested yet
> - a nice 1.2MB/s bandwidth (I'm testing with a 802.11b at client side,
> and AFAIK, bcm43xx does not handle 802.11g yet, does it ?)
>
> *BUT* a big issue : I got a per-connection hang-up at client side on
> strong workloads, for both win32 and linux client side, with my usb
> dongle (which is running ndiswrapper on *nux, sorry for that, I'm
> ashamed of it, silly me, I know, but well... No choice, and the device
> was given me free of charge so...).
> Typical scenario is a ssh session on one hand and a ftp transfer on
> the other. The ftp hangs, while the ssh session stays up and going.
>
> I got no problem with the PCMCIA card (a rock-solid WG511T), on both
> linux and win32.
>
> Of course, the bcm43xx does not say anything about this (if it had
> said so, I would have posted logs along with this complain), so my
> conclusion would be :
>
> Why on earth is this a per-connection issue ? where do I miss
> something ? if I'm really missing packets on one connection, why is
> the other one continuing to live ? I may have forgotten a subtle
> detail of the TCP/IP behaviour here...
Well, I doubt it is a bcm43xx issue. But maybe. Not sure.
Do you run some QoS stuff? Some other quota stuff?
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH, RFT] bcm43xx: AccessPoint mode
From: Francois Barre @ 2006-06-28 19:27 UTC (permalink / raw)
To: Michael Buesch; +Cc: bcm43xx-dev, netdev, Alexander Tsvyashchenko
In-Reply-To: <200606191107.34602.mb@bu3sch.de>
Hi all,
Sorry for answering years after the patch post, I didn't have time to
test this take2 patch before. I had a first look at it a couple of
days ago, but... you know, that was not my day.
> Well, it does not work 100%, but at least it's very promising.
> We are able to create a bssid and correctly send beacon frames out.
[...]
For my very own situation, that is :
- Apple Mini with a BCM 4306 (BigEndian)
- Linux/Win32 boxes with USB and PCMCIA wifi cards (mostly 802.11b usb
at the moment)
Current status is this one :
- master mode functionnal
- dhcp serving, good uptime
- no encryption, WEP or WPA of any kind tested yet
- a nice 1.2MB/s bandwidth (I'm testing with a 802.11b at client side,
and AFAIK, bcm43xx does not handle 802.11g yet, does it ?)
*BUT* a big issue : I got a per-connection hang-up at client side on
strong workloads, for both win32 and linux client side, with my usb
dongle (which is running ndiswrapper on *nux, sorry for that, I'm
ashamed of it, silly me, I know, but well... No choice, and the device
was given me free of charge so...).
Typical scenario is a ssh session on one hand and a ftp transfer on
the other. The ftp hangs, while the ssh session stays up and going.
I got no problem with the PCMCIA card (a rock-solid WG511T), on both
linux and win32.
Of course, the bcm43xx does not say anything about this (if it had
said so, I would have posted logs along with this complain), so my
conclusion would be :
Why on earth is this a per-connection issue ? where do I miss
something ? if I'm really missing packets on one connection, why is
the other one continuing to live ? I may have forgotten a subtle
detail of the TCP/IP behaviour here... Or may that be all about window
scaling and fragmentation ? I can not see anything else... I would at
least like to know what to test, as I'm a little bit confused here.
Yes, I'll try to dig around the ip window and timeout stuff by tonight...
Anyway, I would like to thank again and again Alexander and Michael
for the work done, that is really impressive. Great work !
Best regards,
F. B.
^ 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