* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Jozsef Kadlecsik @ 2011-01-18 20:18 UTC (permalink / raw)
To: holger; +Cc: netfilter-devel, netdev
In-Reply-To: <20110118142247.498399684@eitzenberger.org>
On Tue, 18 Jan 2011, holger@eitzenberger.org wrote:
> While the following works for AF_INET:
>
> ipset add foo 192.168.1.1/32
>
> this does not work for AF_INET6:
>
> ipset add foo6 20a1:1:2:3:4:5:6:7/128
> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
The complete fix was to add the exception to the generic IP address parser
function.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: [PATCH] af_unix: implement socket filter
From: Eric Dumazet @ 2011-01-18 20:19 UTC (permalink / raw)
To: Alban Crequy
Cc: Ian Molton, netdev, linux-kernel, davem, ebiederm, xemul, davidel
In-Reply-To: <20110118175143.3a164669@chocolatine.cbg.collabora.co.uk>
Le mardi 18 janvier 2011 à 17:51 +0000, Alban Crequy a écrit :
> Le Tue, 18 Jan 2011 18:22:41 +0100,
> Eric Dumazet <eric.dumazet@gmail.com> a écrit :
> > Any idea on performance cost adding sk_filter() call ?
>
> Ian will write a performance test and repost the patch with some stats.
> I don't know about the performance cost.
Dont spend time on this, it was more a question for myself ;)
Cost should be very small, unless complex filter is used, and I have a
JIT compiler for BPF on x86_64, will post it when net-next-2.6 reopens.
^ permalink raw reply
* Re: [patch 4/4] ipset: fix build with NDEBUG defined
From: Jozsef Kadlecsik @ 2011-01-18 20:20 UTC (permalink / raw)
To: holger; +Cc: netfilter-devel, netdev
In-Reply-To: <20110118142248.489615870@eitzenberger.org>
On Tue, 18 Jan 2011, holger@eitzenberger.org wrote:
> The usage of the gcc option -Wunused-parameter interferes badly with
> the assert() macros. In case -DNDEBUG is specified build fails with:
>
> cc1: warnings being treated as errors
> print.c: In function 'ipset_print_family':
> print.c:92: error: unused parameter 'opt'
> print.c: In function 'ipset_print_port':
> print.c:413: error: unused parameter 'opt'
> print.c: In function 'ipset_print_proto':
>
> A possible fix is just to remove -Wunused, as -Wextra + -Wunused enables
> -Wunused-paramter.
I chose to keep the compiler flags and add the required attribute to the
function parameters instead.
Many thanks again, Holger!
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* pull request: wireless-2.6 2010-01-18
From: John W. Linville @ 2011-01-18 20:21 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Dave,
Here is another batch of fixes intended for 2.6.38. Included are a
locking fix, and endian fix, a lockdep fix, an error code fix, a memory
leak fix, a type fix, and a couple of others.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 16c0f9362433a76f01d174bb8b9c87b9a96198ee:
qeth: l3 hw tx csum circumvent hw bug (2011-01-15 20:45:57 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Amitkumar Karwar (1):
ieee80211: correct IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK macro
Axel Lin (1):
iwmc3200wifi: Return proper error for iwm_if_alloc
Bob Copeland (1):
ath5k: fix locking in tx_complete_poll_work
Jesper Juhl (1):
rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
Johannes Berg (1):
mac80211: fix lockdep warning
Luciano Coelho (1):
mac80211: use maximum number of AMPDU frames as default in BA RX
Luis R. Rodriguez (1):
ath9k_hw: ASPM interoperability fix for AR9380/AR9382
Rajkumar Manoharan (2):
ath9k_htc: Fix endian issue in tx header
ath9k_hw: do PA offset calibration only on longcal interval
Wey-Yi Guy (1):
iwlwifi: fix valid chain reading from EEPROM
drivers/net/wireless/ath/ath5k/base.c | 4 ++++
drivers/net/wireless/ath/ath9k/ar9002_calib.c | 10 +++++-----
.../net/wireless/ath/ath9k/ar9003_2p2_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 ++--
drivers/net/wireless/ath/ath9k/htc.h | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 8 +++++---
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 2 +-
drivers/net/wireless/iwmc3200wifi/netdev.c | 2 ++
drivers/net/wireless/rt2x00/rt2x00firmware.c | 1 +
include/linux/ieee80211.h | 2 +-
net/mac80211/agg-rx.c | 11 ++---------
net/mac80211/main.c | 12 +++++++++++-
12 files changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 019a74d..09ae4ef 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -2294,6 +2294,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
int i;
bool needreset = false;
+ mutex_lock(&sc->lock);
+
for (i = 0; i < ARRAY_SIZE(sc->txqs); i++) {
if (sc->txqs[i].setup) {
txq = &sc->txqs[i];
@@ -2321,6 +2323,8 @@ ath5k_tx_complete_poll_work(struct work_struct *work)
ath5k_reset(sc, NULL, true);
}
+ mutex_unlock(&sc->lock);
+
ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work,
msecs_to_jiffies(ATH5K_TX_COMPLETE_POLL_INT));
}
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_calib.c b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
index ea2e7d7..5e300bd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_calib.c
+++ b/drivers/net/wireless/ath/ath9k/ar9002_calib.c
@@ -679,10 +679,6 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
/* Do NF cal only at longer intervals */
if (longcal || nfcal_pending) {
- /* Do periodic PAOffset Cal */
- ar9002_hw_pa_cal(ah, false);
- ar9002_hw_olc_temp_compensation(ah);
-
/*
* Get the value from the previous NF cal and update
* history buffer.
@@ -697,8 +693,12 @@ static bool ar9002_hw_calibrate(struct ath_hw *ah,
ath9k_hw_loadnf(ah, ah->curchan);
}
- if (longcal)
+ if (longcal) {
ath9k_hw_start_nfcal(ah, false);
+ /* Do periodic PAOffset Cal */
+ ar9002_hw_pa_cal(ah, false);
+ ar9002_hw_olc_temp_compensation(ah);
+ }
}
return iscaldone;
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
index 81f9cf2..9ecca93 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_2p2_initvals.h
@@ -1842,7 +1842,7 @@ static const u32 ar9300_2p2_soc_preamble[][2] = {
static const u32 ar9300PciePhy_pll_on_clkreq_disable_L1_2p2[][2] = {
/* Addr allmodes */
- {0x00004040, 0x08212e5e},
+ {0x00004040, 0x0821265e},
{0x00004040, 0x0008003b},
{0x00004044, 0x00000000},
};
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index 6137634..06fb2c8 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -146,8 +146,8 @@ static void ar9003_hw_init_mode_regs(struct ath_hw *ah)
/* Sleep Setting */
INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
- ar9300PciePhy_clkreq_enable_L1_2p2,
- ARRAY_SIZE(ar9300PciePhy_clkreq_enable_L1_2p2),
+ ar9300PciePhy_pll_on_clkreq_disable_L1_2p2,
+ ARRAY_SIZE(ar9300PciePhy_pll_on_clkreq_disable_L1_2p2),
2);
/* Fast clock modal settings */
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 1ce506f..780ac5e 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -78,7 +78,7 @@ struct tx_frame_hdr {
u8 node_idx;
u8 vif_idx;
u8 tidno;
- u32 flags; /* ATH9K_HTC_TX_* */
+ __be32 flags; /* ATH9K_HTC_TX_* */
u8 key_type;
u8 keyix;
u8 reserved[26];
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 33f3602..7a5ffca 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -113,6 +113,7 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
if (ieee80211_is_data(fc)) {
struct tx_frame_hdr tx_hdr;
+ u32 flags = 0;
u8 *qc;
memset(&tx_hdr, 0, sizeof(struct tx_frame_hdr));
@@ -136,13 +137,14 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv, struct sk_buff *skb)
/* Check for RTS protection */
if (priv->hw->wiphy->rts_threshold != (u32) -1)
if (skb->len > priv->hw->wiphy->rts_threshold)
- tx_hdr.flags |= ATH9K_HTC_TX_RTSCTS;
+ flags |= ATH9K_HTC_TX_RTSCTS;
/* CTS-to-self */
- if (!(tx_hdr.flags & ATH9K_HTC_TX_RTSCTS) &&
+ if (!(flags & ATH9K_HTC_TX_RTSCTS) &&
(priv->op_flags & OP_PROTECT_ENABLE))
- tx_hdr.flags |= ATH9K_HTC_TX_CTSONLY;
+ flags |= ATH9K_HTC_TX_CTSONLY;
+ tx_hdr.flags = cpu_to_be32(flags);
tx_hdr.key_type = ath9k_cmn_get_hw_crypto_keytype(skb);
if (tx_hdr.key_type == ATH9K_KEY_TYPE_CLEAR)
tx_hdr.keyix = (u8) ATH9K_TXKEYIX_INVALID;
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 97906dd..14ceb4d 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -168,7 +168,7 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
/* not using .cfg overwrite */
radio_cfg = iwl_eeprom_query16(priv, EEPROM_RADIO_CONFIG);
priv->cfg->valid_tx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
- priv->cfg->valid_rx_ant = EEPROM_RF_CFG_TX_ANT_MSK(radio_cfg);
+ priv->cfg->valid_rx_ant = EEPROM_RF_CFG_RX_ANT_MSK(radio_cfg);
if (!priv->cfg->valid_tx_ant || !priv->cfg->valid_rx_ant) {
IWL_ERR(priv, "Invalid chain (0X%x, 0X%x)\n",
priv->cfg->valid_tx_ant,
diff --git a/drivers/net/wireless/iwmc3200wifi/netdev.c b/drivers/net/wireless/iwmc3200wifi/netdev.c
index 13a69eb..5091d77 100644
--- a/drivers/net/wireless/iwmc3200wifi/netdev.c
+++ b/drivers/net/wireless/iwmc3200wifi/netdev.c
@@ -126,6 +126,7 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
ndev = alloc_netdev_mq(0, "wlan%d", ether_setup, IWM_TX_QUEUES);
if (!ndev) {
dev_err(dev, "no memory for network device instance\n");
+ ret = -ENOMEM;
goto out_priv;
}
@@ -138,6 +139,7 @@ void *iwm_if_alloc(int sizeof_bus, struct device *dev,
GFP_KERNEL);
if (!iwm->umac_profile) {
dev_err(dev, "Couldn't alloc memory for profile\n");
+ ret = -ENOMEM;
goto out_profile;
}
diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
index f0e1eb7..be0ff78 100644
--- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
+++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
@@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
if (!fw || !fw->size || !fw->data) {
ERROR(rt2x00dev, "Failed to read Firmware.\n");
+ release_firmware(fw);
return -ENOENT;
}
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 6042228..294169e 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -959,7 +959,7 @@ struct ieee80211_ht_info {
/* block-ack parameters */
#define IEEE80211_ADDBA_PARAM_POLICY_MASK 0x0002
#define IEEE80211_ADDBA_PARAM_TID_MASK 0x003C
-#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFA0
+#define IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK 0xFFC0
#define IEEE80211_DELBA_PARAM_TID_MASK 0xF000
#define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index f138b19..227ca82 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -185,8 +185,6 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
struct ieee80211_mgmt *mgmt,
size_t len)
{
- struct ieee80211_hw *hw = &local->hw;
- struct ieee80211_conf *conf = &hw->conf;
struct tid_ampdu_rx *tid_agg_rx;
u16 capab, tid, timeout, ba_policy, buf_size, start_seq_num, status;
u8 dialog_token;
@@ -231,13 +229,8 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
goto end_no_lock;
}
/* determine default buffer size */
- if (buf_size == 0) {
- struct ieee80211_supported_band *sband;
-
- sband = local->hw.wiphy->bands[conf->channel->band];
- buf_size = IEEE80211_MIN_AMPDU_BUF;
- buf_size = buf_size << sband->ht_cap.ampdu_factor;
- }
+ if (buf_size == 0)
+ buf_size = IEEE80211_MAX_AMPDU_BUF;
/* examine state machine */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 485d36b..a46ff06 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -39,6 +39,8 @@ module_param(ieee80211_disable_40mhz_24ghz, bool, 0644);
MODULE_PARM_DESC(ieee80211_disable_40mhz_24ghz,
"Disable 40MHz support in the 2.4GHz band");
+static struct lock_class_key ieee80211_rx_skb_queue_class;
+
void ieee80211_configure_filter(struct ieee80211_local *local)
{
u64 mc;
@@ -569,7 +571,15 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
spin_lock_init(&local->filter_lock);
spin_lock_init(&local->queue_stop_reason_lock);
- skb_queue_head_init(&local->rx_skb_queue);
+ /*
+ * The rx_skb_queue is only accessed from tasklets,
+ * but other SKB queues are used from within IRQ
+ * context. Therefore, this one needs a different
+ * locking class so our direct, non-irq-safe use of
+ * the queue's lock doesn't throw lockdep warnings.
+ */
+ skb_queue_head_init_class(&local->rx_skb_queue,
+ &ieee80211_rx_skb_queue_class);
INIT_DELAYED_WORK(&local->scan_work, ieee80211_scan_work);
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
From: Jay Vosburgh @ 2011-01-18 20:24 UTC (permalink / raw)
To: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?=
Cc: Oleg V. Ukhno, John Fastabend, David S. Miller,
netdev@vger.kernel.org, =?UTF-8?B?U8OpYmFzdGllbiBCYXJyw6k=?=,
Christophe Paasch
In-Reply-To: <4D35BED5.7040301@gmail.com>
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>Le 18/01/2011 16:28, Oleg V. Ukhno a écrit :
>> On 01/18/2011 05:54 PM, Nicolas de Pesloüan wrote:
>>> I remember a topology (described by Jay, for as far as I remember),
>>> where two hosts were connected through two distinct VLANs. In such
>>> topology:
>>> - it is possible to detect path failure using arp monitoring instead of
>>> miimon.
I don't think this is true, at least not for the case of
balance-rr. Using ARP monitoring with any sort of load balance scheme
is problematic, because the replies may be balanced to a different slave
than the sender.
>>> - changing the destination MAC address of egress packets are not
>>> necessary, because egress path selection force ingress path selection
>>> due to the VLAN.
This is true, with one comment: Oleg's proposal we're discussing
changes the source MAC address of outgoing packets, not the destination.
The purpose being to manipulate the src-mac balancing algorithm on the
switch when the packets are hashed at the egress port channel group.
The packets (for a particular destination) all bear the same destination
MAC, but (as I understand it) are manually assigned tailored source MAC
addresses that hash to sequential values.
>> In case with two VLANs - yes, this shouldn't be necessary(but needs to
>> be tested, I am not sure), but within one - it is essential for correct
>> rx load striping.
>
>Changing the destination MAC address is definitely not required if you
>segregate each path in a distinct VLAN.
>
> +-------------------+ +-------------------+
> +-------|switch 1 - vlan 100|-----|switch 2 - vlan 100|-------+
> | +-------------------+ +-------------------+ |
>+------+ | | +------+
>|host A| | | |host B|
>+------+ | | +------+
> | +-------------------+ +-------------------+ |
> +-------|switch 3 - vlan 200|-----|switch 4 - vlan 200|-------+
> +-------------------+ +-------------------+
>
>Even in the present of ISL between some switches, packet sent through host
>A interface connected to vlan 100 will only enter host B using the
>interface connected to vlan 100. So every slaves of the bonding interface
>can use the same MAC address.
That's true. The big problem with the "VLAN tunnel" approach is
that it's not tolerant of link failures.
>Of course, changing the destination address would be required in order to
>achieve ingress load balancing on a *single* LAN. But, as Jay noted at the
>beginning of this thread, this would violate 802.3ad.
>
>>> I think the only point is whether we need a new xmit_hash_policy for
>>> mode=802.3ad or whether mode=balance-rr could be enough.
>> May by, but it seems to me fair enough not to restrict this feature only
>> to non-LACP aggregate links; dynamic aggregation may be useful(it helps
>> to avoid switch misconfiguration(misconfigured slaves on switch side)
>> sometimes without loss of service).
>
>You are right, but such LAN setup need to be carefully designed and
>built. I'm not sure that an automatic channel aggregation system is the
>right way to do it. Hence the reason why I suggest to use balance-rr with
>VLANs.
The "VLAN tunnel" approach is a derivative of an actual switch
topology that balance-rr was originally intended for, many moons ago.
This is described in the current bonding.txt; I'll cut & paste a bit
here:
12.2 Maximum Throughput in a Multiple Switch Topology
-----------------------------------------------------
Multiple switches may be utilized to optimize for throughput
when they are configured in parallel as part of an isolated network
between two or more systems, for example:
+-----------+
| Host A |
+-+---+---+-+
| | |
+--------+ | +---------+
| | |
+------+---+ +-----+----+ +-----+----+
| Switch A | | Switch B | | Switch C |
+------+---+ +-----+----+ +-----+----+
| | |
+--------+ | +---------+
| | |
+-+---+---+-+
| Host B |
+-----------+
In this configuration, the switches are isolated from one
another. One reason to employ a topology such as this is for an
isolated network with many hosts (a cluster configured for high
performance, for example), using multiple smaller switches can be more
cost effective than a single larger switch, e.g., on a network with 24
hosts, three 24 port switches can be significantly less expensive than
a single 72 port switch.
If access beyond the network is required, an individual host
can be equipped with an additional network device connected to an
external network; this host then additionally acts as a gateway.
[end of cut]
This was described to me some time ago as an early usage model
for balance-rr using multiple 10 Mb/sec switches. It has the same link
monitoring problems as the "VLAN tunnel" approach, although modern
switches with "trunk failover" type of functionality may be able to
mitigate the problem.
>>> Oleg, would you mind trying the above "two VLAN" topology" with
>>> mode=balance-rr and report any results ? For high-availability purpose,
>>> it's obviously necessary to setup those VLAN on distinct switches.
>> I'll do it, but it will take some time to setup test environment,
>> several days may be.
>
>Thanks. For testing purpose, it is enough to setup those VLAN on a single
>switch if it is easier for you to do.
>
>> You mean following topology:
>
>See above.
>
>> (i'm sure it will work as desired if each host is connected to each
>> switch with only one slave link, if there are more slaves in each switch
>> - unsure)?
>
>If you want to use more than 2 slaves per host, then you need more than 2
>VLAN. You also need to have the exact same number of slaves on all hosts,
>as egress path selection cause ingress path selection at the other side.
>
> +-------------------+ +-------------------+
> +-------|switch 1 - vlan 100|-----|switch 2 - vlan 100|-------+
> | +-------------------+ +-------------------+ |
>+------+ | | +------+
>|host A| | | |host B|
>+------+ | | +------+
> | | +-------------------+ +-------------------+ | |
> | +-------|switch 3 - vlan 200|-----|switch 4 - vlan 200|-------+ |
> | +-------------------+ +-------------------+ |
> | | | |
> | | | |
> | +-------------------+ +-------------------+ |
> +---------|switch 5 - vlan 300|-----|switch 6 - vlan 300|---------+
> +-------------------+ +-------------------+
>
>Of course, you can add others host to vlan 100, 200 and 300, with the
>exact same configuration at host A or host B.
This is essentially the same thing as the diagram I pasted in up
above, except with VLANs and an additional layer of switches between the
hosts. The multiple VLANs take the place of multiple discrete switches.
This could also be accomplished via bridge groups (in
Cisco-speak). For example, instead of VLAN 100, that could be bridge
group X, VLAN 200 is bridge group Y, and so on.
Neither the VLAN nor the bridge group methods handle link
failures very well; if, in the above diagram, the link from "switch 2
vlan 100" to "host B" fails, there's no way for host A to know to stop
sending to "switch 1 vlan 100," and there's no backup path for VLAN 100
to "host B."
One item I'd like to see some more data on is the level of
reordering at the receiver in Oleg's system.
One of the reasons round robin isn't as useful as it once was is
due to the rise of NAPI and interrupt coalescing, both of which will
tend to increase the reordering of packets at the receiver when the
packets are evenly striped. In the old days, it was one interrupt, one
packet. Now, it's one interrupt or NAPI poll, many packets. With the
packets striped across interfaces, this will tend to increase
reordering. E.g.,
slave 1 slave 2 slave 3
Packet 1 P2 P3
P4 P5 P6
P7 P8 P9
and so on. A poll of slave 1 will get packets 1, 4 and 7 (and
probably several more), then a poll of slave 2 will get 2, 5 and 8, etc.
I haven't done much testing with this lately, but I suspect this
behavior hasn't really changed. Raising the tcp_reordering sysctl value
can mitigate this somewhat (by making TCP more tolerant of this), but
that doesn't help non-TCP protocols.
Barring evidence to the contrary, I presume that Oleg's system
delivers out of order at the receiver. That's not automatically a
reason to reject it, but this entire proposal is sufficiently complex to
configure that very explicit documentation will be necessary.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Jan Engelhardt @ 2011-01-18 20:25 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: holger, netfilter-devel, netdev
In-Reply-To: <alpine.DEB.2.00.1101182116150.28203@blackhole.kfki.hu>
On Tuesday 2011-01-18 21:18, Jozsef Kadlecsik wrote:
>On Tue, 18 Jan 2011, holger@eitzenberger.org wrote:
>
>> While the following works for AF_INET:
>>
>> ipset add foo 192.168.1.1/32
>>
>> this does not work for AF_INET6:
>>
>> ipset add foo6 20a1:1:2:3:4:5:6:7/128
>> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
>
>Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
>IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
(Assuming this was a question, heuristically based on the word order
you used:) I don't think so. iptables, resp. its modules, do not
allow that either.
^ permalink raw reply
* Re: [PATCH] vhost: rcu annotation fixup
From: Paul E. McKenney @ 2011-01-18 20:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Jason Wang, kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20110118201031.GC18760@redhat.com>
On Tue, Jan 18, 2011 at 10:10:31PM +0200, Michael S. Tsirkin wrote:
> On Tue, Jan 18, 2011 at 11:02:33AM -0800, Paul E. McKenney wrote:
> > On Tue, Jan 18, 2011 at 07:55:00PM +0200, Michael S. Tsirkin wrote:
> > > On Tue, Jan 18, 2011 at 09:48:34AM -0800, Paul E. McKenney wrote:
> > > > On Tue, Jan 18, 2011 at 01:08:45PM +0200, Michael S. Tsirkin wrote:
> > > > > When built with rcu checks enabled, vhost triggers
> > > > > bogus warnings as vhost features are read without
> > > > > dev->mutex sometimes.
> > > > > Fixing it properly is not trivial as vhost.h does not
> > > > > know which lockdep classes it will be used under.
> > > > > Disable the warning by stubbing out the check for now.
> > > > >
> > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > ---
> > > > > drivers/vhost/vhost.h | 4 +---
> > > > > 1 files changed, 1 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
> > > > > index 2af44b7..2d03a31 100644
> > > > > --- a/drivers/vhost/vhost.h
> > > > > +++ b/drivers/vhost/vhost.h
> > > > > @@ -173,9 +173,7 @@ static inline int vhost_has_feature(struct vhost_dev *dev, int bit)
> > > > > {
> > > > > unsigned acked_features;
> > > > >
> > > > > - acked_features =
> > > > > - rcu_dereference_index_check(dev->acked_features,
> > > > > - lockdep_is_held(&dev->mutex));
> > > > > + acked_features = rcu_dereference_index_check(dev->acked_features, 1);
> > > >
> > > > Ouch!!!
> > > >
> > > > Could you please at least add a comment?
> > >
> > > Yes, OK.
> > >
> > > > Alternatively, pass in the lock that is held and check for that? Given
> > > > that this is a static inline, the compiler should be able to optimize
> > > > the argument away when !PROVE_RCU, correct?
> > > >
> > > > Thanx, Paul
> > >
> > > Hopefully, yes. We don't always have a lock: the idea was
> > > to create a lockdep for these cases. But we can't pass
> > > the pointer to that ...
> >
> > I suppose you could pass a pointer to the lockdep map structure.
> > Not sure if this makes sense, but it would handle the situation.
>
> Will it compile with lockdep disabled too? What will the pointer be?
One (crude) approach would be to make the pointer void* if lockdep
is disabled.
> > Alternatively, create a helper function that checks the possibilities
> > and screams if none of them are in effect.
> >
> > Thanx, Paul
>
> The problem here is the callee needs to know about all callers.
As does the guy reading the code. ;-)
Thanx, Paul
> > > > > return acked_features & (1 << bit);
> > > > > }
> > > > >
> > > > > --
> > > > > 1.7.3.2.91.g446ac
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > > > the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > > > Please read the FAQ at http://www.tux.org/lkml/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: WARNING in module rt2870sta stable kernel 2.6.37
From: Eric Dumazet @ 2011-01-18 20:30 UTC (permalink / raw)
To: Giangiacomo Mariotti; +Cc: devel, netdev, Greg KH, linux-kernel
In-Reply-To: <AANLkTi=HsE+h9GU8rM6zW2BVtoayEGfKOmPCsrrNHiz5@mail.gmail.com>
Le mardi 18 janvier 2011 à 21:16 +0100, Giangiacomo Mariotti a écrit :
> Hi, the following message was logged on a 2.6.37 kernel(it says
> tainted, but it's actually a micro patch I wrote and applied on top of
> current 2.6.37 vanilla, patch appended, but it should be irrelevant, I
> just shut up a bunch of useless debug output for this staging driver):
Thats a known problem
Please try following patch
[PATCH] staging, rt2860: fix panic
Its now illegal to call netif_stop_queue() before register_netdev()
(commit e6484930d7 ("net: allocate tx queues inregister_netdevice")
Reported-by: Giangiacomo Mariotti <gg.mariotti@gmail.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
drivers/staging/rt2860/rt_main_dev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/rt2860/rt_main_dev.c b/drivers/staging/rt2860/rt_main_dev.c
index 701561d..236dd36 100644
--- a/drivers/staging/rt2860/rt_main_dev.c
+++ b/drivers/staging/rt2860/rt_main_dev.c
@@ -484,8 +484,6 @@ struct net_device *RtmpPhyNetDevInit(struct rt_rtmp_adapter *pAd,
net_dev->ml_priv = (void *)pAd;
pAd->net_dev = net_dev;
- netif_stop_queue(net_dev);
-
return net_dev;
}
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
^ permalink raw reply related
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Pablo Neira Ayuso @ 2011-01-18 20:31 UTC (permalink / raw)
To: Jarek Poplawski
Cc: David Miller, arthur.marsh, jengelh, eric.dumazet, netdev, hadi
In-Reply-To: <20110118102437.GB7520@ff.dom.local>
On 18/01/11 11:24, Jarek Poplawski wrote:
> On Tue, Jan 18, 2011 at 02:07:02AM -0800, David Miller wrote:
>> From: Jarek Poplawski <jarkao2@gmail.com>
>> Date: Tue, 18 Jan 2011 09:38:11 +0000
>>
>>> Even if I'm wrong, this change added to stable will break many configs.
>>> My proposal is to revert commit 0ab03c2b147 until proper fix is found.
>>
>> The flag combination is, at best ambiguous, it has no proper
>> definition without the check we added.
>
> Do you all expect all users manage to upgrade avahi app before
> changing their stable kernel? I mean "own distro" users especially.
The combination that avahi uses makes no sense.
I've been auditing user-space tools that may have problems with this change:
* iw (it uses libnl)
* acpid (it uses a mangled version of libnetlink shipped in iproute)
* tstime, for taskstats, it uses libnl
* wimax-tools, it uses libnl
* quota-tools, it uses libnl
* keepalived, no libs used
Well, I can keep looking for more, but I think that avahi is the only
one doing this incorrectly.
Please, fix avahi instead.
^ permalink raw reply
* Re: WARNING in module rt2870sta stable kernel 2.6.37
From: Eric Dumazet @ 2011-01-18 20:33 UTC (permalink / raw)
To: Denis Kirjanov; +Cc: Giangiacomo Mariotti, Greg KH, devel, linux-kernel, netdev
In-Reply-To: <AANLkTi=-4k0hbM9gESLBfzJW_reonqX_GMiVzXzRJFqu@mail.gmail.com>
Le mardi 18 janvier 2011 à 23:25 +0300, Denis Kirjanov a écrit :
> I have sent a patch to fix this problem: https://lkml.org/lkml/2011/1/10/329
> It also fixes a bug #26472: https://bugzilla.kernel.org/show_bug.cgi?id=26472
OK, next time CC netdev so that we can Ack your patches ;)
^ permalink raw reply
* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Jozsef Kadlecsik @ 2011-01-18 20:37 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: holger, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1101182121310.19007@obet.zrqbmnf.qr>
On Tue, 18 Jan 2011, Jan Engelhardt wrote:
> On Tuesday 2011-01-18 21:18, Jozsef Kadlecsik wrote:
> >On Tue, 18 Jan 2011, holger@eitzenberger.org wrote:
> >
> >> While the following works for AF_INET:
> >>
> >> ipset add foo 192.168.1.1/32
> >>
> >> this does not work for AF_INET6:
> >>
> >> ipset add foo6 20a1:1:2:3:4:5:6:7/128
> >> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
> >
> >Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
> >IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
>
> (Assuming this was a question, heuristically based on the word order
> you used:) I don't think so. iptables, resp. its modules, do not
> allow that either.
I know, but the situation is a little bit more complicated: the set type
in question works differently with IPv4 and IPv6. In the IPv4 case, a
range of IP addresses as IPv4/prefix is accepted as input (thus
192.168.1.1/32 too), while for IPv6, only plain IPv6 addresses are allowed
and therefore 20a1:1:2:3:4:5:6:7/128 was rejected.
That looks really odd so I added the feature (but could not resist to add
my comment as a pseudo-question :-).
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: David Miller @ 2011-01-18 20:39 UTC (permalink / raw)
To: hadi; +Cc: jarkao2, pablo, arthur.marsh, jengelh, eric.dumazet, netdev
In-Reply-To: <1295359503.2066.10.camel@mojatatu>
From: jamal <hadi@cyberus.ca>
Date: Tue, 18 Jan 2011 09:05:03 -0500
> On Tue, 2011-01-18 at 10:24 +0000, Jarek Poplawski wrote:
>
>> Do you all expect all users manage to upgrade avahi app before
>> changing their stable kernel? I mean "own distro" users especially.
>
> Unfortunately if that app is widely deployed, it is not pragmatic
> to break it in the name of pedanticity. i.e.
> Be conservative in what you send (clearly Avahi is farting all over the
> place) but more importantly be a nice liberal in what you accept.
> Maybe tell them if you have the cycles about their bad behavior.
> The important part is the GET (kind = 2). The DUMP as Jarek says
> is merely a utility to extrapolate that we need you to
> get everything.. So it is not such a big deal if someone passes
> extraneous senseless flags. Wrong? yes.
Fair enough, I'll revert the netlink patch.
^ permalink raw reply
* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Jan Engelhardt @ 2011-01-18 20:39 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: holger, netfilter-devel, netdev
In-Reply-To: <alpine.DEB.2.00.1101182128210.28350@blackhole.kfki.hu>
On Tuesday 2011-01-18 21:37, Jozsef Kadlecsik wrote:
>> >>
>> >> this does not work for AF_INET6:
>> >>
>> >> ipset add foo6 20a1:1:2:3:4:5:6:7/128
>> >> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
>> >
>> >Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
>> >IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
>>
>> (Assuming this was a question, heuristically based on the word order
>> you used:) I don't think so. iptables, resp. its modules, do not
>> allow that either.
>
>I know, but the situation is a little bit more complicated: the set type
>in question works differently with IPv4 and IPv6. In the IPv4 case, a
>range of IP addresses as IPv4/prefix is accepted as input (thus
>192.168.1.1/32 too), while for IPv6, only plain IPv6 addresses are allowed
>and therefore 20a1:1:2:3:4:5:6:7/128 was rejected.
Is there a specific reason that there is no IPv6 net support?
^ permalink raw reply
* tool to send unsolicited neighbour advertisements?
From: Chris Friesen @ 2011-01-18 20:42 UTC (permalink / raw)
To: netdev, Linux Kernel Mailing List
Hi,
We're transitioning stuff to IPv6 and I've been trying (without much
luck) to find a standard tool for sending out unsolicited neighbour
advertisements for failover purposes.
Is there such a thing? In ipv4 arping works fine.
Thanks,
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: David Miller @ 2011-01-18 20:50 UTC (permalink / raw)
To: pablo; +Cc: jarkao2, arthur.marsh, jengelh, eric.dumazet, netdev, hadi
In-Reply-To: <4D35F8A3.1010600@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 18 Jan 2011 21:31:31 +0100
> The combination that avahi uses makes no sense.
>
> I've been auditing user-space tools that may have problems with this change:
>
> * iw (it uses libnl)
> * acpid (it uses a mangled version of libnetlink shipped in iproute)
> * tstime, for taskstats, it uses libnl
> * wimax-tools, it uses libnl
> * quota-tools, it uses libnl
> * keepalived, no libs used
>
> Well, I can keep looking for more, but I think that avahi is the only
> one doing this incorrectly.
>
> Please, fix avahi instead.
That's a pretty compelling argument, so I'll hold off on the revert
for now.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-01-18
From: David Miller @ 2011-01-18 20:51 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20110118202135.GA15402@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 18 Jan 2011 15:21:35 -0500
> Here is another batch of fixes intended for 2.6.38. Included are a
> locking fix, and endian fix, a lockdep fix, an error code fix, a memory
> leak fix, a type fix, and a couple of others.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Jozsef Kadlecsik @ 2011-01-18 20:54 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: holger, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1101182139030.19166@obet.zrqbmnf.qr>
On Tue, 18 Jan 2011, Jan Engelhardt wrote:
> On Tuesday 2011-01-18 21:37, Jozsef Kadlecsik wrote:
> >> >>
> >> >> this does not work for AF_INET6:
> >> >>
> >> >> ipset add foo6 20a1:1:2:3:4:5:6:7/128
> >> >> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
> >> >
> >> >Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
> >> >IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
> >>
> >> (Assuming this was a question, heuristically based on the word order
> >> you used:) I don't think so. iptables, resp. its modules, do not
> >> allow that either.
> >
> >I know, but the situation is a little bit more complicated: the set type
> >in question works differently with IPv4 and IPv6. In the IPv4 case, a
> >range of IP addresses as IPv4/prefix is accepted as input (thus
> >192.168.1.1/32 too), while for IPv6, only plain IPv6 addresses are allowed
> >and therefore 20a1:1:2:3:4:5:6:7/128 was rejected.
>
> Is there a specific reason that there is no IPv6 net support?
Call it laziness: for IPv6, the hash:ip* types does *not* accept a
range of elements to be added/deleted in one command, expressed as
ipset add foo6 20a1:1:2:3:4:5:6:7/120
or
ipset add foo6 20A1:1:2:3:4:5:6:0-20A1:1:2:3:4:5:6:FF
For IPv4 the syntax is accepted and handled.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Jarek Poplawski @ 2011-01-18 20:55 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Miller, arthur.marsh, jengelh, eric.dumazet, netdev, hadi
In-Reply-To: <4D35F8A3.1010600@netfilter.org>
On Tue, Jan 18, 2011 at 09:31:31PM +0100, Pablo Neira Ayuso wrote:
> On 18/01/11 11:24, Jarek Poplawski wrote:
> > On Tue, Jan 18, 2011 at 02:07:02AM -0800, David Miller wrote:
> >> From: Jarek Poplawski <jarkao2@gmail.com>
> >> Date: Tue, 18 Jan 2011 09:38:11 +0000
> >>
> >>> Even if I'm wrong, this change added to stable will break many configs.
> >>> My proposal is to revert commit 0ab03c2b147 until proper fix is found.
> >>
> >> The flag combination is, at best ambiguous, it has no proper
> >> definition without the check we added.
> >
> > Do you all expect all users manage to upgrade avahi app before
> > changing their stable kernel? I mean "own distro" users especially.
>
> The combination that avahi uses makes no sense.
I don't agree as explained in the reverting patch. Anyway, again,
this is an old problem, so no reason to force "fixing" it just now
at the expense of the obvious regression especially in stable kernels
Anyway, I'll accept any David's decision wrt this problem.
Jarek P.
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
From: Nicolas de Pesloüan @ 2011-01-18 21:20 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Oleg V. Ukhno, John Fastabend, David S. Miller,
netdev@vger.kernel.org, Sébastien Barré,
Christophe Paasch
In-Reply-To: <28837.1295382268@death>
Le 18/01/2011 21:24, Jay Vosburgh a écrit :
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
>>>> - it is possible to detect path failure using arp monitoring instead of
>>>> miimon.
>
> I don't think this is true, at least not for the case of
> balance-rr. Using ARP monitoring with any sort of load balance scheme
> is problematic, because the replies may be balanced to a different slave
> than the sender.
Cannot we achieve the expected arp monitoring by using the exact same artifice that Oleg suggested:
using a different source MAC per slave for arp monitoring, so that return path match sending path ?
>>>> - changing the destination MAC address of egress packets are not
>>>> necessary, because egress path selection force ingress path selection
>>>> due to the VLAN.
>
> This is true, with one comment: Oleg's proposal we're discussing
> changes the source MAC address of outgoing packets, not the destination.
> The purpose being to manipulate the src-mac balancing algorithm on the
> switch when the packets are hashed at the egress port channel group.
> The packets (for a particular destination) all bear the same destination
> MAC, but (as I understand it) are manually assigned tailored source MAC
> addresses that hash to sequential values.
Yes, you're right.
> That's true. The big problem with the "VLAN tunnel" approach is
> that it's not tolerant of link failures.
Yes, except if we find a way to make arp monitoring reliable in load balancing situation.
[snip]
> This is essentially the same thing as the diagram I pasted in up
> above, except with VLANs and an additional layer of switches between the
> hosts. The multiple VLANs take the place of multiple discrete switches.
>
> This could also be accomplished via bridge groups (in
> Cisco-speak). For example, instead of VLAN 100, that could be bridge
> group X, VLAN 200 is bridge group Y, and so on.
>
> Neither the VLAN nor the bridge group methods handle link
> failures very well; if, in the above diagram, the link from "switch 2
> vlan 100" to "host B" fails, there's no way for host A to know to stop
> sending to "switch 1 vlan 100," and there's no backup path for VLAN 100
> to "host B."
Can't we imagine to "arp monitor" the destination MAC address of host B, on both paths ? That way,
host A would know that a given path is down, because return path would be the same. The target host
should send the reply on the slave on which it receive the request, which is the normal way to reply
to arp request.
> One item I'd like to see some more data on is the level of
> reordering at the receiver in Oleg's system.
This is exactly the reason why I asked Oleg to do some test with balance-rr. I cannot find a good
reason for a possibly new xmit_hash_policy to provide better throughput than current balance-rr. If
the throughput increase by, let's say, less than 20%, whatever tcp_reordering value, then it is
probably a dead end way.
> One of the reasons round robin isn't as useful as it once was is
> due to the rise of NAPI and interrupt coalescing, both of which will
> tend to increase the reordering of packets at the receiver when the
> packets are evenly striped. In the old days, it was one interrupt, one
> packet. Now, it's one interrupt or NAPI poll, many packets. With the
> packets striped across interfaces, this will tend to increase
> reordering. E.g.,
>
> slave 1 slave 2 slave 3
> Packet 1 P2 P3
> P4 P5 P6
> P7 P8 P9
>
> and so on. A poll of slave 1 will get packets 1, 4 and 7 (and
> probably several more), then a poll of slave 2 will get 2, 5 and 8, etc.
Any chance to receive P1, P2, P3 on slave 1, P4, P5, P6 on slave 2 et P7, P8, P9 on slave3, possibly
by sending grouped packets, changing the sending slave every N packets instead of every packet ? I
think we already discussed this possibility a few months or years ago in bonding-devel ML. For as
far as I remember, the idea was not developed because it was not easy to find the number of packets
to send through the same slave. Anyway, this might help reduce out of order delivery.
> Barring evidence to the contrary, I presume that Oleg's system
> delivers out of order at the receiver. That's not automatically a
> reason to reject it, but this entire proposal is sufficiently complex to
> configure that very explicit documentation will be necessary.
Yes, and this is already true for some bonding modes and in particular for balance-rr.
Nicolas.
^ permalink raw reply
* Re: Flow Control and Port Mirroring Revisited
From: Rick Jones @ 2011-01-18 21:28 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Horman, Jesse Gross, Eric Dumazet, Rusty Russell,
virtualization, dev, virtualization, netdev, kvm
In-Reply-To: <20110118201333.GD18760@redhat.com>
Michael S. Tsirkin wrote:
> On Tue, Jan 18, 2011 at 11:41:22AM -0800, Rick Jones wrote:
>
>>PS - the enhanced latency statistics from -j are only available in
>>the "omni" version of the TCP_RR test. To get that add a
>>--enable-omni to the ./configure - and in this case both netperf and
>>netserver have to be recompiled.
>
> Is this TCP only? I would love to get latency data from UDP as well.
I believe it will work with UDP request response as well. The omni test code
strives to be protocol agnostic. (I'm sure there are bugs of course, there
always are.)
There is though the added complication of there being no specific matching of
requests to responses. The code as written takes advantage of TCP's in-order
semantics and recovery from packet loss. In a "plain" UDP_RR test, with one at
a time transactions, if either the request or response are lost, data flow
effectively stops there until the timer expires. So, one has "reasonable" RTT
numbers from before that point. In a burst UDP RR test, the code doesn't know
which request/response was lost and so the matching being done to get RTTs will
be off by each lost datagram. And if something were re-ordered the timstamps
would be off even without a datagram loss event.
To "fix" that would require netperf do something it has not yet done in 18-odd
years :) That is actually echo something back from the netserver on the RR test
- either an id, or a timestamp. That means "dirtying" the buffers which means
still more cache misses, from places other than the actual stack. Not beyond the
realm of the possible, but it would be a bit of departure for "normal" operation
(*) and could enforce a minimum request/response size beyond the present single
byte (ok, perhaps only two or four bytes :). But that, perhaps, is a discussion
best left to netperf-talk at netperf.org.
happy benchmarking,
rick jones
(*) netperf does have the concept of reading from and/or dirtying buffers,
put-in back in the days of COW/page-remapping in HP-UX 9.0, but that was mainly
to force COW and/or show the effect of the required data cache purges/flushes.
As such it was made conditional on DIRTY being defined.
^ permalink raw reply
* Re: inbound connection problems when "netlink: test for all flags of the NLM_F_DUMP composite" commit applied
From: Jarek Poplawski @ 2011-01-18 21:14 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: David Miller, arthur.marsh, jengelh, eric.dumazet, netdev, hadi
In-Reply-To: <4D35F8A3.1010600@netfilter.org>
On Tue, Jan 18, 2011 at 09:31:31PM +0100, Pablo Neira Ayuso wrote:
> On 18/01/11 11:24, Jarek Poplawski wrote:
> > On Tue, Jan 18, 2011 at 02:07:02AM -0800, David Miller wrote:
> >> From: Jarek Poplawski <jarkao2@gmail.com>
> >> Date: Tue, 18 Jan 2011 09:38:11 +0000
> >>
> >>> Even if I'm wrong, this change added to stable will break many configs.
> >>> My proposal is to revert commit 0ab03c2b147 until proper fix is found.
> >>
> >> The flag combination is, at best ambiguous, it has no proper
> >> definition without the check we added.
> >
> > Do you all expect all users manage to upgrade avahi app before
> > changing their stable kernel? I mean "own distro" users especially.
>
> The combination that avahi uses makes no sense.
>
> I've been auditing user-space tools that may have problems with this change:
>
> * iw (it uses libnl)
> * acpid (it uses a mangled version of libnetlink shipped in iproute)
> * tstime, for taskstats, it uses libnl
> * wimax-tools, it uses libnl
> * quota-tools, it uses libnl
> * keepalived, no libs used
>
> Well, I can keep looking for more, but I think that avahi is the only
> one doing this incorrectly.
BTW, could you answer my earlier question, why NLM_F_ATOMIC flag isn't
handled now with dumps?
Jarek P.
^ permalink raw reply
* Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6
From: Hans de Bruin @ 2011-01-18 21:42 UTC (permalink / raw)
To: Jesse Gross; +Cc: LKML, netdev
In-Reply-To: <AANLkTinejKw0pY5HncB2e0ocjqYuCwTBUwd2xkroWu+E@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3491 bytes --]
On 01/18/2011 09:06 PM, Jesse Gross wrote:
> On Tue, Jan 18, 2011 at 11:52 AM, Hans de Bruin<jmdebruin@xmsnet.nl> wrote:
>> On 01/16/2011 09:24 PM, Hans de Bruin wrote:
>>>
>>> After last nights compile i lost the possibility to connect to ssh and
>>> http over ipv6. The connection stops at syn_sent. connections to my
>>> machine end in syn_recv. ping6 still works.
>>>
>>
>> The bisect ended in:
>>
>> 0363466866d901fbc658f4e63dd61e7cc93dd0af is the first bad commit
>> commit 0363466866d901fbc658f4e63dd61e7cc93dd0af
>> Author: Jesse Gross<jesse@nicira.com>
>> Date: Sun Jan 9 06:23:35 2011 +0000
>>
>> net offloading: Convert checksums to use centrally computed features.
>>
>> In order to compute the features for other offloads (primarily
>> scatter/gather), we need to first check the ability of the NIC to
>> offload the checksum for the packet. Since we have already computed
>> this, we can directly use the result instead of figuring it out
>> again.
>>
>> Signed-off-by: Jesse Gross<jesse@nicira.com>
>> Signed-off-by: David S. Miller<davem@davemloft.net>
>>
>>
>> ssh ::1 still works. And since dns still works I guess udp is not affected.
>> My nic is a:
>>
>> 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit
>> Ethernet PCI Express (rev 02)
>
> Are you using vlans? If so, can you please test this patch?
> http://patchwork.ozlabs.org/patch/79264/
>
No I am not using vlans. The option is even not set in the config file.
Except for the disk less bit is a straightforward setup:
bash-4.1# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
qlen 1000
link/ether 00:1c:23:2d:73:87 brd ff:ff:ff:ff:ff:ff
inet 10.10.0.6/16 brd 10.10.255.255 scope global eth0
inet6 2001:610:76e:0:21c:23ff:fe2d:7387/64 scope global dynamic
valid_lft 86399sec preferred_lft 14399sec
inet6 fe80::21c:23ff:fe2d:7387/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
link/sit 0.0.0.0 brd 0.0.0.0
bash-4.1# ip route show
10.10.0.0/16 dev eth0 proto kernel scope link src 10.10.0.6
default via 10.10.0.1 dev eth0
bash-4.1# ip -6 route show
2001:610:76e::/64 dev eth0 proto kernel metric 256 expires 86404sec
fe80::/64 dev eth0 proto kernel metric 256
ff00::/8 dev eth0 metric 256
default via fe80::230:18ff:feae:75d8 dev eth0 proto kernel metric 1024
expires 29sec hoplimit 64
bash-4.1# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
bash-4.1# ip6tables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
bash-4.1# brctl show
bridge name bridge id STP enabled interfaces
bash-4.1# cat /proc/cmdline
root=/dev/nfs nfsroot=10.10.0.2:/nfs/root/psion/,v3,tcp ro ip=::: ::dhcp
BOOT_IMAGE=nightlybuild-psion
--
Hans
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 14483 bytes --]
^ permalink raw reply
* Re: [patch 2/4] ipset: make IPv4 and IPv6 address handling similar
From: Holger Eitzenberger @ 2011-01-18 21:43 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Jozsef Kadlecsik, netfilter-devel, netdev
In-Reply-To: <alpine.LNX.2.01.1101182139030.19166@obet.zrqbmnf.qr>
On Tue, Jan 18, 2011 at 09:39:32PM +0100, Jan Engelhardt wrote:
> On Tuesday 2011-01-18 21:37, Jozsef Kadlecsik wrote:
> >> >>
> >> >> this does not work for AF_INET6:
> >> >>
> >> >> ipset add foo6 20a1:1:2:3:4:5:6:7/128
> >> >> ipset v5.2: Syntax error: plain IP address must be supplied: 20a1:1:2:3:4:5:6:7/128
> >> >
> >> >Yeah, the usual issue: should IPv4/32 and IPv6/128 be handled as a plain
> >> >IPv4/v6 address when the manual says "enter a plain IPv4/v6 address" :-).
> >>
> >> (Assuming this was a question, heuristically based on the word order
> >> you used:) I don't think so. iptables, resp. its modules, do not
> >> allow that either.
> >
> >I know, but the situation is a little bit more complicated: the set type
> >in question works differently with IPv4 and IPv6. In the IPv4 case, a
> >range of IP addresses as IPv4/prefix is accepted as input (thus
> >192.168.1.1/32 too), while for IPv6, only plain IPv6 addresses are allowed
> >and therefore 20a1:1:2:3:4:5:6:7/128 was rejected.
>
> Is there a specific reason that there is no IPv6 net support?
You shouldn't use hash:ip with ranges for IPv4 too because the range
members are added individually, which is less efficient both memory
and performance wise, see:
$ ipset create foo hash:ip hashsize 64
$ ipset add foo 192.168.1.0/30
$ ipset list foo
Name: foo
Type: hash:ip
Header: family inet hashsize 64 maxelem 65536
Size in memory: 628
References: 0
Members:
192.168.1.3
192.168.1.2
192.168.1.0
192.168.1.1
> Call it laziness: for IPv6, the hash:ip* types does *not* accept a
> range of elements to be added/deleted in one command, expressed as
>
> ipset add foo6 20a1:1:2:3:4:5:6:7/120
>
> or
>
> ipset add foo6 20A1:1:2:3:4:5:6:0-20A1:1:2:3:4:5:6:FF
>
> For IPv4 the syntax is accepted and handled.
^ permalink raw reply
* Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6
From: Eric Dumazet @ 2011-01-18 22:03 UTC (permalink / raw)
To: Hans de Bruin; +Cc: Jesse Gross, LKML, netdev
In-Reply-To: <4D36092B.1090406@xmsnet.nl>
Le mardi 18 janvier 2011 à 22:42 +0100, Hans de Bruin a écrit :
> On 01/18/2011 09:06 PM, Jesse Gross wrote:
> > On Tue, Jan 18, 2011 at 11:52 AM, Hans de Bruin<jmdebruin@xmsnet.nl> wrote:
> >> On 01/16/2011 09:24 PM, Hans de Bruin wrote:
> >>>
> >>> After last nights compile i lost the possibility to connect to ssh and
> >>> http over ipv6. The connection stops at syn_sent. connections to my
> >>> machine end in syn_recv. ping6 still works.
> >>>
> >>
> >> The bisect ended in:
> >>
> >> 0363466866d901fbc658f4e63dd61e7cc93dd0af is the first bad commit
> >> commit 0363466866d901fbc658f4e63dd61e7cc93dd0af
> >> Author: Jesse Gross<jesse@nicira.com>
> >> Date: Sun Jan 9 06:23:35 2011 +0000
> >>
> >> net offloading: Convert checksums to use centrally computed features.
> >>
> >> In order to compute the features for other offloads (primarily
> >> scatter/gather), we need to first check the ability of the NIC to
> >> offload the checksum for the packet. Since we have already computed
> >> this, we can directly use the result instead of figuring it out
> >> again.
> >>
> >> Signed-off-by: Jesse Gross<jesse@nicira.com>
> >> Signed-off-by: David S. Miller<davem@davemloft.net>
> >>
> >>
> >> ssh ::1 still works. And since dns still works I guess udp is not affected.
> >> My nic is a:
> >>
> >> 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit
> >> Ethernet PCI Express (rev 02)
> >
> > Are you using vlans? If so, can you please test this patch?
> > http://patchwork.ozlabs.org/patch/79264/
> >
>
> No I am not using vlans. The option is even not set in the config file.
> Except for the disk less bit is a straightforward setup:
>
> bash-4.1# ip addr show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
> qlen 1000
> link/ether 00:1c:23:2d:73:87 brd ff:ff:ff:ff:ff:ff
> inet 10.10.0.6/16 brd 10.10.255.255 scope global eth0
> inet6 2001:610:76e:0:21c:23ff:fe2d:7387/64 scope global dynamic
> valid_lft 86399sec preferred_lft 14399sec
> inet6 fe80::21c:23ff:fe2d:7387/64 scope link
> valid_lft forever preferred_lft forever
> 3: sit0: <NOARP> mtu 1480 qdisc noop state DOWN
> link/sit 0.0.0.0 brd 0.0.0.0
> bash-4.1# ip route show
> 10.10.0.0/16 dev eth0 proto kernel scope link src 10.10.0.6
> default via 10.10.0.1 dev eth0
> bash-4.1# ip -6 route show
> 2001:610:76e::/64 dev eth0 proto kernel metric 256 expires 86404sec
> fe80::/64 dev eth0 proto kernel metric 256
> ff00::/8 dev eth0 metric 256
> default via fe80::230:18ff:feae:75d8 dev eth0 proto kernel metric 1024
> expires 29sec hoplimit 64
> bash-4.1# iptables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> bash-4.1# ip6tables -L
> Chain INPUT (policy ACCEPT)
> target prot opt source destination
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> bash-4.1# brctl show
> bridge name bridge id STP enabled interfaces
> bash-4.1# cat /proc/cmdline
> root=/dev/nfs nfsroot=10.10.0.2:/nfs/root/psion/,v3,tcp ro ip=::: ::dhcp
> BOOT_IMAGE=nightlybuild-psion
>
You could try "tcpdump -i eth0 ip6 -v"
I guess you receive frames with bad checksums
You can ask other system to not offload tx checksums
ethtool -K eth0 tx off
Please give result of (on both machines)
lspci -v
^ permalink raw reply
* Re: [PATCH] bonding: added 802.3ad round-robin hashing policy for single TCP session balancing
From: Oleg V. Ukhno @ 2011-01-18 22:22 UTC (permalink / raw)
To: Jay Vosburgh
Cc: Nicolas de Pesloüan, John Fastabend, David S. Miller,
netdev@vger.kernel.org, Sébastien Barré,
Christophe Paasch
In-Reply-To: <28837.1295382268@death>
Jay Vosburgh wrote:
>
> One item I'd like to see some more data on is the level of
> reordering at the receiver in Oleg's system.
>
> One of the reasons round robin isn't as useful as it once was is
> due to the rise of NAPI and interrupt coalescing, both of which will
> tend to increase the reordering of packets at the receiver when the
> packets are evenly striped. In the old days, it was one interrupt, one
> packet. Now, it's one interrupt or NAPI poll, many packets. With the
> packets striped across interfaces, this will tend to increase
> reordering. E.g.,
>
> slave 1 slave 2 slave 3
> Packet 1 P2 P3
> P4 P5 P6
> P7 P8 P9
>
> and so on. A poll of slave 1 will get packets 1, 4 and 7 (and
> probably several more), then a poll of slave 2 will get 2, 5 and 8, etc.
>
> I haven't done much testing with this lately, but I suspect this
> behavior hasn't really changed. Raising the tcp_reordering sysctl value
> can mitigate this somewhat (by making TCP more tolerant of this), but
> that doesn't help non-TCP protocols.
>
> Barring evidence to the contrary, I presume that Oleg's system
> delivers out of order at the receiver. That's not automatically a
> reason to reject it, but this entire proposal is sufficiently complex to
> configure that very explicit documentation will be necessary.
Jay, here is some network stats from one of my iSCSI targets with avg
load of 1.5-2.5Gbit/sec(4 slaves in etherchannel).Not perfect and not
very "clean"(there are more interfaces on host, than these 4)
[root@<somehost> ~]# netstat -st
IcmpMsg:
InType0: 6
InType3: 1872
InType8: 60557
InType11: 23
OutType0: 60528
OutType3: 1755
OutType8: 6
Tcp:
1298909 active connections openings
61090 passive connection openings
2374 failed connection attempts
62781 connection resets received
3 connections established
1268233942 segments received
1198020318 segments send out
18939618 segments retransmited
0 bad segments received.
23643 resets sent
TcpExt:
294935 TCP sockets finished time wait in fast timer
472 time wait sockets recycled by time stamp
819481 delayed acks sent
295332 delayed acks further delayed because of locked socket
Quick ack mode was activated 30616377 times
3516920 packets directly queued to recvmsg prequeue.
4353 packets directly received from backlog
44873453 packets directly received from prequeue
1442812750 packets header predicted
1077442 packets header predicted and directly queued to user
2123453975 acknowledgments not containing data received
2375328274 predicted acknowledgments
8462439 times recovered from packet loss due to fast retransmit
Detected reordering 19203 times using reno fast retransmit
Detected reordering 100 times using time stamp
3429 congestion windows fully recovered
11760 congestion windows partially recovered using Hoe heuristic
398 congestion windows recovered after partial ack
0 TCP data loss events
3671 timeouts after reno fast retransmit
6 timeouts in loss state
18919118 fast retransmits
11637 retransmits in slow start
1756 other TCP timeouts
TCPRenoRecoveryFail: 3187
62779 connections reset due to early user close
IpExt:
InBcastPkts: 512616
[root@<somehost> ~]# uptime
00:35:49 up 42 days, 8:27, 1 user, load average: 3.70, 3.80, 4.07
[root@<somehost> ~]# sysctl -a|grep tcp_reo
net.ipv4.tcp_reordering = 3
I will get back with "clean" results after I'll setup test system tomorrow.
TcpExt stats from other hosts are similar.
>
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
--
Best regards,
Oleg Ukhno
^ 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