* Re: Hight speed data sending from custom IP out of kernel
From: Eric Dumazet @ 2011-04-21 8:18 UTC (permalink / raw)
To: monstr; +Cc: juice, netdev
In-Reply-To: <4DAFE4A0.2030905@monstr.eu>
Le jeudi 21 avril 2011 à 10:02 +0200, Michal Simek a écrit :
> Thanks for that. I am looking at pktgen. On UDP my system is able to send full
> bandwidth on 100Mbit/s ethernet and 220Mbit/s on 1G/s.
> I will let you know when I have any useful resutls.
220Mbits/s in pktgen or an application ?
- how many packets per second ? (or packet size ?)
pktgen has the "clone_skb 100" thing that avoid skb_alloc()/skb_free()
overhead, and permits to really test driver performance.
It also bypass qdisc management.
^ permalink raw reply
* rfkill-input to be removed
From: Marco Chiappero @ 2011-04-21 8:28 UTC (permalink / raw)
To: netdev; +Cc: johannes
While working on the the sony-laptop driver, adding support for
persistent rfkill state storing and adding the SW_RFKILL_ALL switch
event forwarding to the input core to notify userspace, I realized that
rfkill-input interferes with correct behavior of the driver, vanishing
the hardware device state storing. Then, looking at
Documentation/feature-removal-schedule.txt I realized that rfkill-input
was scheduled to be removed in 2.6.33, but it's still there in 2.6.39.
Please remove that code as soon as possible, rfkill input events should
be handled by user space tools.
^ permalink raw reply
* Re: [PATCH] tg3: Convert u32 flag,flg2,flg3 uses to bitmap
From: Eric Dumazet @ 2011-04-21 8:31 UTC (permalink / raw)
To: Joe Perches; +Cc: Matt Carlson, Michael Chan, netdev, linux-kernel
In-Reply-To: <02bf2aa5c08514641ecbe7c39ef976918fad036c.1303367730.git.joe@perches.com>
Le mercredi 20 avril 2011 à 23:39 -0700, Joe Perches a écrit :
> Using a bitmap instead of separate u32 flags allows a consistent, simpler
> and more extensible mechanism to determine capabilities.
>
> Convert bitfields to indexes.
> Add tg3_flag, tg3_flag_clear and tg3_flag_set
> Convert the flag & bitmask tests.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/tg3.c | 1262 ++++++++++++++++++++++++++---------------------------
> drivers/net/tg3.h | 164 ++++----
> 2 files changed, 696 insertions(+), 730 deletions(-)
Use an enum ?
Why first value is 1 and not 0 ?
> +#define TG3_FLAG_TAGGED_STATUS 1
> +#define TG3_FLAG_TXD_MBOX_HWBUG 2
> +#define TG3_FLAG_USE_LINKCHG_REG 3
> +#define TG3_FLAG_ERROR_PROCESSED 4
> +#define TG3_FLAG_ENABLE_ASF 5
> +#define TG3_FLAG_ASPM_WORKAROUND 6
> +#define TG3_FLAG_POLL_SERDES 7
> +#define TG3_FLAG_MBOX_WRITE_REORDER 8
> +#define TG3_FLAG_PCIX_TARGET_HWBUG 9
> +#define TG3_FLAG_WOL_SPEED_100MB 10
> +#define TG3_FLAG_WOL_ENABLE 11
> +#define TG3_FLAG_EEPROM_WRITE_PROT 12
> +#define TG3_FLAG_NVRAM 13
> +#define TG3_FLAG_NVRAM_BUFFERED 14
> +#define TG3_FLAG_SUPPORT_MSI 15
> +#define TG3_FLAG_SUPPORT_MSIX 16
> +#define TG3_FLAG_PCIX_MODE 17
> +#define TG3_FLAG_PCI_HIGH_SPEED 18
> +#define TG3_FLAG_PCI_32BIT 19
> +#define TG3_FLAG_SRAM_USE_CONFIG 20
> +#define TG3_FLAG_TX_RECOVERY_PENDING 21
> +#define TG3_FLAG_WOL_CAP 22
> +#define TG3_FLAG_JUMBO_RING_ENABLE 23
> +#define TG3_FLAG_PAUSE_AUTONEG 24
> +#define TG3_FLAG_CPMU_PRESENT 25
> +#define TG3_FLAG_40BIT_DMA_BUG 26
> +#define TG3_FLAG_BROKEN_CHECKSUMS 27
> +#define TG3_FLAG_JUMBO_CAPABLE 28
> +#define TG3_FLAG_CHIP_RESETTING 29
> +#define TG3_FLAG_INIT_COMPLETE 30
> +#define TG3_FLAG_RESTART_TIMER 31
> +#define TG3_FLAG_TSO_BUG 32
> +#define TG3_FLAG_IS_5788 33
> +#define TG3_FLAG_MAX_RXPEND_64 34
> +#define TG3_FLAG_TSO_CAPABLE 35
> +#define TG3_FLAG_PCI_EXPRESS 36
> +#define TG3_FLAG_ASF_NEW_HANDSHAKE 37
> +#define TG3_FLAG_HW_AUTONEG 38
> +#define TG3_FLAG_IS_NIC 39
> +#define TG3_FLAG_FLASH 40
> +#define TG3_FLAG_HW_TSO_1 41
> +#define TG3_FLAG_5705_PLUS 42
> +#define TG3_FLAG_5750_PLUS 43
> +#define TG3_FLAG_HW_TSO_3 44
> +#define TG3_FLAG_USING_MSI 45
> +#define TG3_FLAG_USING_MSIX 46
> +#define TG3_FLAG_ICH_WORKAROUND 47
> +#define TG3_FLAG_5780_CLASS 48
> +#define TG3_FLAG_HW_TSO_2 49
> +#define TG3_FLAG_1SHOT_MSI 50
> +#define TG3_FLAG_NO_FWARE_REPORTED 51
> +#define TG3_FLAG_NO_NVRAM_ADDR_TRANS 52
> +#define TG3_FLAG_ENABLE_APE 53
> +#define TG3_FLAG_PROTECTED_NVRAM 54
> +#define TG3_FLAG_5701_DMA_BUG 55
> +#define TG3_FLAG_USE_PHYLIB 56
> +#define TG3_FLAG_MDIOBUS_INITED 57
> +#define TG3_FLAG_LRG_PROD_RING_CAP 58
> +#define TG3_FLAG_RGMII_INBAND_DISABLE 59
> +#define TG3_FLAG_RGMII_EXT_IBND_RX_EN 60
> +#define TG3_FLAG_RGMII_EXT_IBND_TX_EN 61
> +#define TG3_FLAG_CLKREQ_BUG 62
> +#define TG3_FLAG_5755_PLUS 63
> +#define TG3_FLAG_NO_NVRAM 64
> +#define TG3_FLAG_ENABLE_RSS 65
> +#define TG3_FLAG_ENABLE_TSS 66
> +#define TG3_FLAG_4G_DMA_BNDRY_BUG 67
> +#define TG3_FLAG_40BIT_DMA_LIMIT_BUG 68
> +#define TG3_FLAG_SHORT_DMA_BUG 69
> +#define TG3_FLAG_USE_JUMBO_BDFLAG 70
> +#define TG3_FLAG_L1PLLPD_EN 71
> +#define TG3_FLAG_57765_PLUS 72
> +#define TG3_FLAG_APE_HAS_NCSI 73
> +#define TG3_FLAG_5717_PLUS 74
> +#define TG3_FLAGS 74 /* Set to number of flags */
> +
> struct tg3 {
> /* begin "general, frequently-used members" cacheline section */
>
> @@ -2838,7 +2914,7 @@ struct tg3 {
> /* SMP locking strategy:
> *
> * lock: Held during reset, PHY access, timer, and when
> - * updating tg3_flags and tg3_flags2.
> + * updating tg3_flags.
> *
> * netif_tx_lock: Held during tg3_start_xmit. tg3_tx holds
> * netif_tx_lock when it needs to call
> @@ -2895,95 +2971,13 @@ struct tg3 {
> struct tg3_ethtool_stats estats;
> struct tg3_ethtool_stats estats_prev;
>
> + DECLARE_BITMAP(tg3_flags, TG3_FLAGS);
> +
Also you need to make TG3_FLAGS be (last_flag_value + 1) or you could
miss one long in bitmap. (Not now, but later when new flags are added
and reach a multiple of BITS_PER_BYTE * sizeof(long)
^ permalink raw reply
* Re: sis900 transmit timeouts
From: Daniele Venzano @ 2011-04-21 8:34 UTC (permalink / raw)
To: cwillu; +Cc: netdev
In-Reply-To: <BANLkTinTZoTgkNhjhwv=vHwLVgCKQNvKSQ@mail.gmail.com>
I do not the sis900 chipset documentation on hand right now, so I
cannot decode the TX status numbers. I did not receive any more
reports apart from yours and the original one, so it is either a very
nasty bug that happens in very particular conditions or an hardware
problem.
At the time I placed my bets on the 64bit arch because they were rare
enough to make the bug difficult to reproduce.
I'll let you know if your logs give me some hint.
Thanks,
Daniele.
2011/4/21 cwillu <cwillu@cwillu.com>:
> Hi; I'm trying to figure out why the onboard nic on what just became
> my primary desktop disconnects for a few seconds every hour or so.
> After some googling, I came across the "Transmit timeouts" section of
> http://www.brownhat.org/sis900.html, which said to make contact if
> anyone sees this. Granted that that was some time ago, but here's
> hoping somebody still cares :)
>
> I'm running a vanilla 2.6.38 kernel, on 32bit (site said 64bit, but
> given that I see it...).
>
>
> Relevant dmesg:
>
> [ 2.391521] sata_sis 0000:00:05.0: version 1.0
> [ 2.391543] sata_sis 0000:00:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 2.391549] sata_sis 0000:00:05.0: Detected SiS 180/181/964 chipset
> in SATA mode
> [ 2.411447] scsi2 : sata_sis
> [ 2.413472] sis900.c: v1.08.10 Apr. 2 2006
> [ 2.415877] scsi3 : sata_sis
> [ 2.415991] ata3: SATA max UDMA/133 cmd 0xe900 ctl 0xea00 bmdma 0xed00 irq 17
> [ 2.415997] ata4: SATA max UDMA/133 cmd 0xeb00 ctl 0xec00 bmdma 0xed08 irq 17
> [ 2.416187] sis900 0000:00:04.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> [ 2.417375] 0000:00:04.0: Realtek RTL8201 PHY transceiver found at address 1.
> [ 2.427022] 0000:00:04.0: Using transceiver found at address 1 as default
> [ 2.438283] eth0: SiS 900 PCI Fast Ethernet at 0xe400, IRQ 19,
> 00:01:6c:e6:a7:f7
> [ 2.448194] usb 2-2: new low speed USB device using ohci_hcd and address 2
> <snip>
> [ 2337.396544] eth2: Corrupted packet received, buffer status = 0x90880313/787.
> [ 2794.401995] eth2: Transmit error, Tx status 0420004e.
> [ 2870.495324] eth2: Transmit error, Tx status 04200092.
> [ 5351.151451] eth2: Transmit error, Tx status 04200042.
> [ 5591.280818] eth2: Transmit error, Tx status 04200226.
> [ 5612.560354] eth2: Media Link Off
> [ 5622.016027] ------------[ cut here ]------------
> [ 5622.016044] WARNING: at
> /home/kernel-ppa/COD/linux/net/sched/sch_generic.c:256
> dev_watchdog+0x257/0x260()
> [ 5622.016048] Hardware name:
> [ 5622.016051] NETDEV WATCHDOG: eth2 (sis900): transmit queue 0 timed out
> [ 5622.016054] Modules linked in: xt_multiport iptable_filter
> ip_tables x_tables binfmt_misc nfsd lockd nfs_acl auth_rpcgss sunrpc
> exportfs ipx p8023 tuner_simple tuner_types wm8775 tda9887 tda8290
> nouveau tea5767 tuner snd_intel8x0 cx25840 ttm drm_kms_helper ivtv drm
> snd_ac97_codec ac97_bus snd_pcm snd_seq_midi cx2341x snd_rawmidi
> v4l2_common snd_seq_midi_event snd_seq ppdev i2c_algo_bit videodev
> snd_timer parport_pc video tveeprom psmouse snd_seq_device lp parport
> snd soundcore shpchp snd_page_alloc k8temp serio_raw usbhid hid
> sata_sis sis900 floppy raid10 raid1 raid0 multipath linear btrfs
> zlib_deflate libcrc32c
> [ 5622.016117] Pid: 6623, comm: queue0:src Not tainted
> 2.6.38-02063802-generic #201103281246
> [ 5622.016120] Call Trace:
> [ 5622.016127] [<c1449357>] ? dev_watchdog+0x257/0x260
> [ 5622.016134] [<c104fd61>] ? warn_slowpath_common+0x81/0xa0
> [ 5622.016140] [<c1449357>] ? dev_watchdog+0x257/0x260
> [ 5622.016145] [<c104fe23>] ? warn_slowpath_fmt+0x33/0x40
> [ 5622.016150] [<c1449357>] ? dev_watchdog+0x257/0x260
> [ 5622.016155] [<c1068845>] ? __queue_work+0xd5/0x250
> [ 5622.016161] [<c150c10d>] ? _raw_spin_lock+0xd/0x10
> [ 5622.016166] [<c105c904>] ? call_timer_fn+0x34/0xe0
> [ 5622.016171] [<c10f3461>] ? shmem_i_callback+0x21/0x30
> [ 5622.016175] [<c10f3461>] ? shmem_i_callback+0x21/0x30
> [ 5622.016180] [<c1449100>] ? dev_watchdog+0x0/0x260
> [ 5622.016185] [<c105e13c>] ? run_timer_softirq+0xfc/0x1c0
> [ 5622.016189] [<c1449100>] ? dev_watchdog+0x0/0x260
> [ 5622.016195] [<c1055f12>] ? __do_softirq+0x92/0x1a0
> [ 5622.016200] [<c1055e80>] ? __do_softirq+0x0/0x1a0
> [ 5622.016202] <IRQ> [<c105608c>] ? irq_exit+0x6c/0x80
> [ 5622.016211] [<c15134c8>] ? smp_apic_timer_interrupt+0x38/0x42
> [ 5622.016216] [<c150cb89>] ? apic_timer_interrupt+0x31/0x38
> [ 5622.016223] [<c112630d>] ? do_sync_write+0x9d/0xf0
> [ 5622.016229] [<c11264be>] ? rw_verify_area+0x6e/0x130
> [ 5622.016233] [<c1081343>] ? do_futex+0x193/0x1c0
> [ 5622.016238] [<c112682b>] ? vfs_write+0x9b/0x160
> [ 5622.016243] [<c1126270>] ? do_sync_write+0x0/0xf0
> [ 5622.016247] [<c1126e62>] ? sys_write+0x42/0x70
> [ 5622.016253] [<c1002e1f>] ? sysenter_do_call+0x12/0x28
> [ 5622.016257] ---[ end trace 4f85204a75110ff3 ]---
> [ 5622.016262] eth2: Transmit timeout, status 00000004 00000000
> [ 5622.576937] eth2: Media Link On 100mbps full-duplex
>
--
Daniele Venzano
venza@brownhat.org
http://www.brownhat.org
^ permalink raw reply
* [PATCH] ipv6: Remove hoplimit initialization to -1
From: Thomas Egerer @ 2011-04-21 8:56 UTC (permalink / raw)
To: davem; +Cc: netdev
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
The changes introduced with git-commit a02e4b7d missed to remove the
hoplimit initialization. As a result, ipv6_get_mtu interprets the return
value of dst_metric_raw (-1) as 255 and answers ping6 with this hoplimit.
This patche removes the line such that ping6 is answered with the
hoplimit value configured via sysctl.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
---
net/ipv6/route.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
[-- Attachment #2: 0001-ipv6-Remove-hoplimit-initialization-to-1.patch --]
[-- Type: text/x-patch, Size: 416 bytes --]
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 843406f..0a5d02a 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2012,7 +2012,6 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
rt->dst.output = ip6_output;
rt->rt6i_dev = net->loopback_dev;
rt->rt6i_idev = idev;
- dst_metric_set(&rt->dst, RTAX_HOPLIMIT, -1);
rt->dst.obsolete = -1;
rt->rt6i_flags = RTF_UP | RTF_NONEXTHOP;
^ permalink raw reply related
* Re: shutdown oops in xt_compat_calc_jump
From: Patrick McHardy @ 2011-04-21 8:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dann frazier, netdev, netfilter-devel@vger.kernel.org
In-Reply-To: <1302108567.3209.121.camel@edumazet-laptop>
On 06.04.2011 18:49, Eric Dumazet wrote:
> [PATCH] netfilter: fix ebtables
>
> commit 255d0dc34068a976 (netfilter: x_table: speedup compat operations)
> made ebtables not working anymore.
>
> 1) xt_compat_calc_jump() is not an exact match lookup
> 2) compat_table_info() has a typo in xt_compat_init_offsets() call
> 3) compat_do_replace() misses a xt_compat_init_offsets() call
Applied, thanks Eric.
^ permalink raw reply
* Re: Hight speed data sending from custom IP out of kernel
From: Michal Simek @ 2011-04-21 9:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: juice, netdev
In-Reply-To: <1303373925.3685.6.camel@edumazet-laptop>
Eric Dumazet wrote:
> Le jeudi 21 avril 2011 à 10:02 +0200, Michal Simek a écrit :
>
>> Thanks for that. I am looking at pktgen. On UDP my system is able to send full
>> bandwidth on 100Mbit/s ethernet and 220Mbit/s on 1G/s.
>> I will let you know when I have any useful resutls.
>
> 220Mbits/s in pktgen or an application ?
> - how many packets per second ? (or packet size ?)
pktgen - Packet size 1500 on 1Gb/s lan - 66MHx Microblaze cpu without hwcsum
support.
~ # cat /proc/net/pktgen/eth0
Params: count 10000000 min_pkt_size: 1500 max_pkt_size: 1500
frags: 0 delay: 0 clone_skb: 1000000 ifname: eth0
flows: 0 flowlen: 0
queue_map_min: 0 queue_map_max: 0
dst_min: 192.168.0.102 dst_max:
src_min: src_max:
src_mac: 00:0a:35:00:8d:0d dst_mac: 00:12:79:c0:59:15
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 254875 errors: 0
started: 729900351us stopped: 743064495us idle: 26885us
seq_num: 254876 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0xc0a80073 cur_daddr: 0xc0a80066
cur_udp_dst: 9 cur_udp_src: 9
cur_queue_map: 0
flows: 0
Result: OK: 13164144(c13137258+d26885) nsec, 254875 (1500byte,0frags)
19361pps 232Mb/sec (232332000bps) errors: 0
>
> pktgen has the "clone_skb 100" thing that avoid skb_alloc()/skb_free()
> overhead, and permits to really test driver performance.
>
> It also bypass qdisc management.
I have also tried to removed fragments support from the driver to find out what
happen if I remove the part of code from xmit path and there is improvement.
~ # cat /proc/net/pktgen/eth0
Params: count 10000000 min_pkt_size: 1500 max_pkt_size: 1500
frags: 0 delay: 0 clone_skb: 1000000 ifname: eth0
flows: 0 flowlen: 0
queue_map_min: 0 queue_map_max: 0
dst_min: 192.168.0.102 dst_max:
src_min: src_max:
src_mac: 00:0a:35:00:8d:0d dst_mac: 00:12:79:c0:59:15
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 2041908 errors: 0
started: 45216342us stopped: 146752402us idle: 135633us
seq_num: 2041909 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0xc0a80073 cur_daddr: 0xc0a80066
cur_udp_dst: 9 cur_udp_src: 9
cur_queue_map: 0
flows: 0
Result: OK: 101536059(c101400425+d135633) nsec, 2041908 (1500byte,0frags)
20110pps 241Mb/sec (241320000bps) errors: 0
I have also tested frags support and here are results for above configuration.
frags 0 = 232Mb/s
frags 1 = 192Mb/s
frags 2 = 159Mb/s
frags 3 = 141Mb/s
frags 4 = 130Mb/s
frags 5 = 116Mb/s
The eth controller generate irq when tx is done. I measured it yesterday and it
takes 810 timer ticks to send data (1.5k packet size). It is hard to expect how
many cpu instructions it is but maybe half that's why I want to try to disable
IRQ generation and wait when DMA copy is done. Do I have any other options?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
^ permalink raw reply
* [PATCH] be2net: increment work_counter in be_worker
From: Ivan Vecera @ 2011-04-21 10:20 UTC (permalink / raw)
To: netdev; +Cc: sathya.perla, subbu.seetharaman, ajit.khaparde, davem
The commit 609ff3b adds support to display temperature of ASIC but there
is missing increment of work_counter in be_worker. Because of this 1) the
function be_cmd_get_die_temperature is called every 1 second instead of
every 32 seconds 2) be_cmd_get_die_temperature is called, although it is
not supported.
This patch fixes this bug.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/benet/be_main.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
index 7cb5a11..02a0443 100644
--- a/drivers/net/benet/be_main.c
+++ b/drivers/net/benet/be_main.c
@@ -1873,6 +1873,7 @@ static void be_worker(struct work_struct *work)
be_detect_dump_ue(adapter);
reschedule:
+ adapter->work_counter++;
schedule_delayed_work(&adapter->work, msecs_to_jiffies(1000));
}
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 1/1] powerpc: Fix multicast problem in fs_enet driver
From: Andrea Galbusera @ 2011-04-21 12:21 UTC (permalink / raw)
To: Pantelis Antoniou, Vitaly Bordug, Scott Wood
Cc: linuxppc-dev, netdev, linux-kernel, Andrea Galbusera
mac-fec.c was setting individual UDP address registers instead of multicast
group address registers when joining a multicast group.
This prevented from correctly receiving UDP multicast packets.
According to datasheet, replaced hash_table_high and hash_table_low
with grp_hash_table_high and grp_hash_table_low respectively.
Also renamed hash_table_* with grp_hash_table_* in struct fec declaration
for 8xx: these registers are used only for multicast there.
Tested on a MPC5121 based board.
Build tested also against mpc866_ads_defconfig.
Signed-off-by: Andrea Galbusera <gizero@gmail.com>
---
Changes since v1:
Applied comments by Scott Wood to fix 8xx broken build with v1
arch/powerpc/include/asm/8xx_immap.h | 4 ++--
drivers/net/fs_enet/mac-fec.c | 8 ++++----
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/8xx_immap.h b/arch/powerpc/include/asm/8xx_immap.h
index 6b6dc20..bdf0563 100644
--- a/arch/powerpc/include/asm/8xx_immap.h
+++ b/arch/powerpc/include/asm/8xx_immap.h
@@ -393,8 +393,8 @@ typedef struct fec {
uint fec_addr_low; /* lower 32 bits of station address */
ushort fec_addr_high; /* upper 16 bits of station address */
ushort res1; /* reserved */
- uint fec_hash_table_high; /* upper 32-bits of hash table */
- uint fec_hash_table_low; /* lower 32-bits of hash table */
+ uint fec_grp_hash_table_high; /* upper 32-bits of hash table */
+ uint fec_grp_hash_table_low; /* lower 32-bits of hash table */
uint fec_r_des_start; /* beginning of Rx descriptor ring */
uint fec_x_des_start; /* beginning of Tx descriptor ring */
uint fec_r_buff_size; /* Rx buffer size */
diff --git a/drivers/net/fs_enet/mac-fec.c b/drivers/net/fs_enet/mac-fec.c
index 61035fc..b9fbc83 100644
--- a/drivers/net/fs_enet/mac-fec.c
+++ b/drivers/net/fs_enet/mac-fec.c
@@ -226,8 +226,8 @@ static void set_multicast_finish(struct net_device *dev)
}
FC(fecp, r_cntrl, FEC_RCNTRL_PROM);
- FW(fecp, hash_table_high, fep->fec.hthi);
- FW(fecp, hash_table_low, fep->fec.htlo);
+ FW(fecp, grp_hash_table_high, fep->fec.hthi);
+ FW(fecp, grp_hash_table_low, fep->fec.htlo);
}
static void set_multicast_list(struct net_device *dev)
@@ -273,8 +273,8 @@ static void restart(struct net_device *dev)
/*
* Reset all multicast.
*/
- FW(fecp, hash_table_high, fep->fec.hthi);
- FW(fecp, hash_table_low, fep->fec.htlo);
+ FW(fecp, grp_hash_table_high, fep->fec.hthi);
+ FW(fecp, grp_hash_table_low, fep->fec.htlo);
/*
* Set maximum receive buffer size.
--
1.7.0.4
^ permalink raw reply related
* [PATCH net-next-2.6] be2net: Fixed a bug in be_cmd_get_regs().
From: Somnath Kotur @ 2011-04-21 12:49 UTC (permalink / raw)
To: netdev, davem; +Cc: Somnath Kotur
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
---
drivers/net/benet/be_cmds.c | 53 ++++++++++++++++++++++--------------------
1 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index af8cf3d..0fc06d3 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1214,8 +1214,8 @@ int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size)
if (!status) {
struct be_cmd_resp_get_fat *resp = embedded_payload(wrb);
if (log_size && resp->log_size)
- *log_size = le32_to_cpu(resp->log_size -
- sizeof(u32));
+ *log_size = le32_to_cpu(resp->log_size) -
+ sizeof(u32);
}
err:
spin_unlock_bh(&adapter->mcc_lock);
@@ -1228,7 +1228,8 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
struct be_mcc_wrb *wrb;
struct be_cmd_req_get_fat *req;
struct be_sge *sge;
- u32 offset = 0, total_size, buf_size, log_offset = sizeof(u32);
+ u32 offset = 0, total_size, buf_size,
+ log_offset = sizeof(u32), payload_len;
int status;
if (buf_len == 0)
@@ -1236,37 +1237,39 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
total_size = buf_len;
+ get_fat_cmd.size = sizeof(struct be_cmd_req_get_fat) + 60*1024;
+ get_fat_cmd.va = pci_alloc_consistent(adapter->pdev,
+ get_fat_cmd.size,
+ &get_fat_cmd.dma);
+ if (!get_fat_cmd.va) {
+ status = -ENOMEM;
+ dev_err(&adapter->pdev->dev,
+ "Memory allocation failure while retrieving FAT data\n");
+ return;
+ }
+
spin_lock_bh(&adapter->mcc_lock);
- wrb = wrb_from_mccq(adapter);
- if (!wrb) {
- status = -EBUSY;
- goto err;
- }
while (total_size) {
buf_size = min(total_size, (u32)60*1024);
total_size -= buf_size;
- get_fat_cmd.size = sizeof(struct be_cmd_req_get_fat) + buf_size;
- get_fat_cmd.va = pci_alloc_consistent(adapter->pdev,
- get_fat_cmd.size,
- &get_fat_cmd.dma);
- if (!get_fat_cmd.va) {
- status = -ENOMEM;
- dev_err(&adapter->pdev->dev,
- "Memory allocation failure while retrieving FAT data\n");
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
goto err;
}
req = get_fat_cmd.va;
sge = nonembedded_sgl(wrb);
- be_wrb_hdr_prepare(wrb, get_fat_cmd.size, false, 1,
+ payload_len = sizeof(struct be_cmd_req_get_fat) + buf_size;
+ be_wrb_hdr_prepare(wrb, payload_len, false, 1,
OPCODE_COMMON_MANAGE_FAT);
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
- OPCODE_COMMON_MANAGE_FAT, get_fat_cmd.size);
+ OPCODE_COMMON_MANAGE_FAT, payload_len);
- sge->pa_hi = cpu_to_le32(upper_32_bits(get_fat_cmd.size));
+ sge->pa_hi = cpu_to_le32(upper_32_bits(get_fat_cmd.dma));
sge->pa_lo = cpu_to_le32(get_fat_cmd.dma & 0xFFFFFFFF);
sge->len = cpu_to_le32(get_fat_cmd.size);
@@ -1281,17 +1284,17 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
memcpy(buf + offset,
resp->data_buffer,
resp->read_log_length);
- }
- pci_free_consistent(adapter->pdev, get_fat_cmd.size,
- get_fat_cmd.va,
- get_fat_cmd.dma);
- if (status)
+ } else {
dev_err(&adapter->pdev->dev, "FAT Table Retrieve error\n");
-
+ goto err;
+ }
offset += buf_size;
log_offset += buf_size;
}
err:
+ pci_free_consistent(adapter->pdev, get_fat_cmd.size,
+ get_fat_cmd.va,
+ get_fat_cmd.dma);
spin_unlock_bh(&adapter->mcc_lock);
}
--
1.5.6.1
^ permalink raw reply related
* Re: [RFC net-next-2.6] can: replace spinlocks with mutexes
From: Oliver Hartkopp @ 2011-04-21 13:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Linux Netdev List, Kurt Van Dijck, Urs Thuermann
In-Reply-To: <1303313954.3186.117.camel@edumazet-laptop>
On 20.04.2011 17:39, Eric Dumazet wrote:
> Le mercredi 20 avril 2011 à 17:31 +0200, Oliver Hartkopp a écrit :
>> This patch removes spinlocks for the CAN netdevice specific receive lists.
>> The RCU-based receive lists can be modified from process context or from the
>> netdevice notifier call. As both might sleep we can safely replace the
>> spinlocks with mutexes.
>>
>> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
>>
>> ---
>
> But... why ?
>
> A spinlock is faster/smaller than a mutex.
>
> Maybe you wanted to _remove_ spinlock, since/if writer hold RTNL and
> doesnt need to exclude another writer(s) ?
>
> Note : I did not check the RTNL assertion, you might add appropriate
> ASSERT_RTNL() calls just to be 100% safe.
>
I played a bit with rtnl locks but ran into problems with a lock sock when
enabling all locking debug techniques. Therefore i pull back my RFC for now
and leave the locking using spinlocks as-is.
Thanks,
Oliver
^ permalink raw reply
* Re: Suspend/resume - slow resume
From: Francois Romieu @ 2011-04-21 13:02 UTC (permalink / raw)
To: Ciprian Docan
Cc: Linus Torvalds, netdev, Linux Kernel Mailing List, Len Brown,
Pavel Machek, Rafael, J. Wysocki, Greg KH, nic_swsd
In-Reply-To: <Pine.SOC.4.64.1104202204090.1320@er3.rutgers.edu>
Ciprian Docan <docan@eden.rutgers.edu> :
[...]
> @@ -1789,25 +1800,26 @@ rtl_phy_write_fw(struct rtl8169_private *tp, const struct firmware *fw)
>
> static void rtl_release_firmware(struct rtl8169_private *tp)
> {
> - release_firmware(tp->fw);
> - tp->fw = NULL;
> + if (!IS_ERR_OR_NULL(tp->fw))
> + release_firmware(tp->fw);
Ok.
Nit: the test against NULL is not needed here.
--
Ueimor
^ permalink raw reply
* [PATCH net-next-2.6] be2net: Fixed a bug in be_cmd_get_regs().
From: Somnath Kotur @ 2011-04-21 13:18 UTC (permalink / raw)
To: netdev, davem; +Cc: Somnath Kotur
Resending patch as the 'changelog' got missed out in my previous submission.
Same WRB entry was being reused over different iterations of a
loop while issuing non-embedded IOCTL requests.Fixed couple of minor bugs
in this path as well.
Re-factored code to alloc/free memory for DMA outside of loop
Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
---
drivers/net/benet/be_cmds.c | 53 ++++++++++++++++++++++--------------------
1 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/drivers/net/benet/be_cmds.c b/drivers/net/benet/be_cmds.c
index af8cf3d..0fc06d3 100644
--- a/drivers/net/benet/be_cmds.c
+++ b/drivers/net/benet/be_cmds.c
@@ -1214,8 +1214,8 @@ int be_cmd_get_reg_len(struct be_adapter *adapter, u32 *log_size)
if (!status) {
struct be_cmd_resp_get_fat *resp = embedded_payload(wrb);
if (log_size && resp->log_size)
- *log_size = le32_to_cpu(resp->log_size -
- sizeof(u32));
+ *log_size = le32_to_cpu(resp->log_size) -
+ sizeof(u32);
}
err:
spin_unlock_bh(&adapter->mcc_lock);
@@ -1228,7 +1228,8 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
struct be_mcc_wrb *wrb;
struct be_cmd_req_get_fat *req;
struct be_sge *sge;
- u32 offset = 0, total_size, buf_size, log_offset = sizeof(u32);
+ u32 offset = 0, total_size, buf_size,
+ log_offset = sizeof(u32), payload_len;
int status;
if (buf_len == 0)
@@ -1236,37 +1237,39 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
total_size = buf_len;
+ get_fat_cmd.size = sizeof(struct be_cmd_req_get_fat) + 60*1024;
+ get_fat_cmd.va = pci_alloc_consistent(adapter->pdev,
+ get_fat_cmd.size,
+ &get_fat_cmd.dma);
+ if (!get_fat_cmd.va) {
+ status = -ENOMEM;
+ dev_err(&adapter->pdev->dev,
+ "Memory allocation failure while retrieving FAT data\n");
+ return;
+ }
+
spin_lock_bh(&adapter->mcc_lock);
- wrb = wrb_from_mccq(adapter);
- if (!wrb) {
- status = -EBUSY;
- goto err;
- }
while (total_size) {
buf_size = min(total_size, (u32)60*1024);
total_size -= buf_size;
- get_fat_cmd.size = sizeof(struct be_cmd_req_get_fat) + buf_size;
- get_fat_cmd.va = pci_alloc_consistent(adapter->pdev,
- get_fat_cmd.size,
- &get_fat_cmd.dma);
- if (!get_fat_cmd.va) {
- status = -ENOMEM;
- dev_err(&adapter->pdev->dev,
- "Memory allocation failure while retrieving FAT data\n");
+ wrb = wrb_from_mccq(adapter);
+ if (!wrb) {
+ status = -EBUSY;
goto err;
}
req = get_fat_cmd.va;
sge = nonembedded_sgl(wrb);
- be_wrb_hdr_prepare(wrb, get_fat_cmd.size, false, 1,
+ payload_len = sizeof(struct be_cmd_req_get_fat) + buf_size;
+ be_wrb_hdr_prepare(wrb, payload_len, false, 1,
OPCODE_COMMON_MANAGE_FAT);
be_cmd_hdr_prepare(&req->hdr, CMD_SUBSYSTEM_COMMON,
- OPCODE_COMMON_MANAGE_FAT, get_fat_cmd.size);
+ OPCODE_COMMON_MANAGE_FAT, payload_len);
- sge->pa_hi = cpu_to_le32(upper_32_bits(get_fat_cmd.size));
+ sge->pa_hi = cpu_to_le32(upper_32_bits(get_fat_cmd.dma));
sge->pa_lo = cpu_to_le32(get_fat_cmd.dma & 0xFFFFFFFF);
sge->len = cpu_to_le32(get_fat_cmd.size);
@@ -1281,17 +1284,17 @@ void be_cmd_get_regs(struct be_adapter *adapter, u32 buf_len, void *buf)
memcpy(buf + offset,
resp->data_buffer,
resp->read_log_length);
- }
- pci_free_consistent(adapter->pdev, get_fat_cmd.size,
- get_fat_cmd.va,
- get_fat_cmd.dma);
- if (status)
+ } else {
dev_err(&adapter->pdev->dev, "FAT Table Retrieve error\n");
-
+ goto err;
+ }
offset += buf_size;
log_offset += buf_size;
}
err:
+ pci_free_consistent(adapter->pdev, get_fat_cmd.size,
+ get_fat_cmd.va,
+ get_fat_cmd.dma);
spin_unlock_bh(&adapter->mcc_lock);
}
--
1.5.6.1
^ permalink raw reply related
* [PATCH 0/2] Resolve packet capturing on macvlan lowerdev
From: David Ward @ 2011-04-21 13:31 UTC (permalink / raw)
To: netdev, kaber; +Cc: David Ward
The following two patches address situations where macvlan interfaces on
the same lowerdev are created inside separate containers/namespaces, and
traffic between these interfaces needs to be captured by monitoring the
lowerdev outside the containers/namespaces using tcpdump or Wireshark.
The only case where this doesn't work now is for unicast frames when the
macvlan interfaces are operating in bridge mode; this fixes that case.
Should the dev_queue_xmit_nit function be renamed to something more
meaningful, which would indicate its role in sending outgoing frames to
AF_PACKET sockets? It is currently a misnomer: this function used to be
invoked by dev_queue_xmit, but that is no longer the case.
Thanks,
David
David Ward (2):
net: Export dev_queue_xmit_nit for use by macvlan driver
macvlan: Send frames to AF_PACKET sockets attached to lowerdev
drivers/net/macvlan.c | 1 +
include/linux/netdevice.h | 2 ++
net/core/dev.c | 14 +++++++++-----
3 files changed, 12 insertions(+), 5 deletions(-)
--
1.7.4
^ permalink raw reply
* [PATCH 2/2] macvlan: Send frames to AF_PACKET sockets attached to lowerdev
From: David Ward @ 2011-04-21 13:31 UTC (permalink / raw)
To: netdev, kaber; +Cc: David Ward
In-Reply-To: <1303392693-1350-1-git-send-email-david.ward@ll.mit.edu>
In bridge mode, unicast frames can be forwarded directly between macvlan
interfaces attached to the same lowerdev without calling dev_queue_xmit.
These frames should still be sent to any AF_PACKET sockets (network taps)
attached to the lowerdev.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
drivers/net/macvlan.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 3ad5425..2b1ee81 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -237,6 +237,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
dest = macvlan_hash_lookup(port, eth->h_dest);
if (dest && dest->mode == MACVLAN_MODE_BRIDGE) {
+ dev_queue_xmit_nit(skb, vlan->lowerdev);
unsigned int length = skb->len + ETH_HLEN;
int ret = dest->forward(dest->dev, skb);
macvlan_count_rx(dest, length,
--
1.7.4
^ permalink raw reply related
* [PATCH 1/2] net: Export dev_queue_xmit_nit for use by macvlan driver
From: David Ward @ 2011-04-21 13:31 UTC (permalink / raw)
To: netdev, kaber; +Cc: David Ward
In-Reply-To: <1303392693-1350-1-git-send-email-david.ward@ll.mit.edu>
Export dev_queue_xmit_nit for use by the macvlan virtual network device
driver. Also, use 'dev' instead of 'skb->dev' in this function.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
include/linux/netdevice.h | 2 ++
net/core/dev.c | 14 +++++++++-----
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index cb8178a..b63e517 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2099,6 +2099,8 @@ extern int dev_hard_start_xmit(struct sk_buff *skb,
struct netdev_queue *txq);
extern int dev_forward_skb(struct net_device *dev,
struct sk_buff *skb);
+extern void dev_queue_xmit_nit(struct sk_buff *skb,
+ struct net_device *dev);
extern int netdev_budget;
diff --git a/net/core/dev.c b/net/core/dev.c
index 3871bf6..e851227 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1520,11 +1520,13 @@ static inline int deliver_skb(struct sk_buff *skb,
}
/*
- * Support routine. Sends outgoing frames to any network
- * taps currently in use.
+ * dev_queue_xmit_nit - send outgoing frame to AF_PACKET sockets
+ *
+ * @skb: buffer to send
+ * @dev: network device that AF_PACKET sockets are attached to (if any)
*/
-static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
+void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
{
struct packet_type *ptype;
struct sk_buff *skb2 = NULL;
@@ -1539,7 +1541,8 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
(ptype->af_packet_priv == NULL ||
(struct sock *)ptype->af_packet_priv != skb->sk)) {
if (pt_prev) {
- deliver_skb(skb2, pt_prev, skb->dev);
+ atomic_inc(&skb2->users);
+ pt_prev->func(skb2, dev, pt_prev, dev);
pt_prev = ptype;
continue;
}
@@ -1572,9 +1575,10 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
}
}
if (pt_prev)
- pt_prev->func(skb2, skb->dev, pt_prev, skb->dev);
+ pt_prev->func(skb2, dev, pt_prev, dev);
rcu_read_unlock();
}
+EXPORT_SYMBOL(dev_queue_xmit_nit);
/* netif_setup_tc - Handle tc mappings on real_num_tx_queues change
* @dev: Network device
--
1.7.4
^ permalink raw reply related
* Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted
From: Alan Stern @ 2011-04-21 13:43 UTC (permalink / raw)
To: Paul Stewart; +Cc: netdev, linux-usb, davem, greg
In-Reply-To: <BANLkTi=N3T-V8VNOcbKu6COKvbEHqMoAog@mail.gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 2065 bytes --]
On Wed, 20 Apr 2011, Paul Stewart wrote:
> On Wed, Apr 20, 2011 at 2:08 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> > On Tue, 19 Apr 2011, Paul Stewart wrote:
> >
> >> Set a flag if the interrupt URB completes with ENOENT as this
> >> occurs legitimately during system suspend. When the usbnet_bh
> >> is called after resume, test this flag and try once to resubmit
> >> the interrupt URB.
> >
> > No doubt there's a good reason for doing things this way, but it isn't
> > clear. Why wait until usbnet_bh() is called after resume? Why not
> > resubmit the interrupt URB _during_ usbnet_resume()?
>
> Actually, I was doing this in the bh because of feedback I had gained
> early in this process about not doing submit_urb in the resume().
Do you have a URL for that feedback? In general, there's no reason not
to resubmit URBs during a resume callback; lots of drivers do it. But
usbnet may have some special requirements of its own that I'm not aware
of.
> If
> that issue doesn't exist, that makes my work a lot easier. In testing
> I found that just setting this to happen in the bh might be problematic
> due to firing too early, so this is good news.
>
> > This would seem
> > to be the logical approach, seeing as how usbnet_suspend() kills the
> > interrupt URB.
>
> Aha! But you'll see from the current version of my patch that we don't
> actually ever kill the interrupt URB. It gets killed all on its own (by the
> hcd?) and handed back to us in intr_complete(). This last bit about the
> complete function being called was lost on me for a while which is why
> in a previous iteration of the patch I was trying to kill the urb in suspend().
Why not kill the interrupt URB while suspending? It's the proper thing
to do. Otherwise you run the risk that an event might happen at just
the wrong time, causing the interrupt URB to complete normally, but
_after_ the driver has finished suspending. There's a good chance the
driver would not process the event correctly.
Alan Stern
^ permalink raw reply
* Re: rfkill-input to be removed
From: Marco Chiappero @ 2011-04-21 13:47 UTC (permalink / raw)
To: netdev; +Cc: johannes
In-Reply-To: <4DAFEAA7.5090003@absence.it>
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
Il 21/04/2011 10:28, Marco Chiappero ha scritto:
> Please remove that code as soon as possible, rfkill input events should
> be handled by user space tools.
About this topic, I've created a patch right now, you can find it here:
http://www.absence.it/vaio-acpi/source/patches/rfkill-input.patch
Does it look fine?
Moreover, using checkpatch.pl I've found 3 coding style errors, I'm
attaching a patch to fix them (apply this one first).
And just one last thing: as there is no configuration option inside the
menu, shouldn't we change the "menuconfig RFKILL" line to "config
RFKILL" inside net/rfkill/Kconfig?
[-- Attachment #2: rfkill-style.patch --]
[-- Type: text/x-patch, Size: 982 bytes --]
Signed-off-by: Marco Chiappero <marco@absence.it>
--- a/net/rfkill/core.c 2011-04-19 06:26:00.000000000 +0200
+++ b/net/rfkill/core.c 2011-04-21 15:33:21.970094489 +0200
@@ -621,7 +621,7 @@ static ssize_t rfkill_hard_show(struct d
{
struct rfkill *rfkill = to_rfkill(dev);
- return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_HW) ? 1 : 0 );
+ return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_HW) ? 1 : 0);
}
static ssize_t rfkill_soft_show(struct device *dev,
@@ -630,7 +630,7 @@ static ssize_t rfkill_soft_show(struct d
{
struct rfkill *rfkill = to_rfkill(dev);
- return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_SW) ? 1 : 0 );
+ return sprintf(buf, "%d\n", (rfkill->state & RFKILL_BLOCK_SW) ? 1 : 0);
}
static ssize_t rfkill_soft_store(struct device *dev,
@@ -648,7 +648,7 @@ static ssize_t rfkill_soft_store(struct
if (err)
return err;
- if (state > 1 )
+ if (state > 1)
return -EINVAL;
mutex_lock(&rfkill_global_mutex);
^ permalink raw reply
* Re: Hight speed data sending from custom IP out of kernel
From: zhou rui @ 2011-04-21 13:56 UTC (permalink / raw)
To: juice; +Cc: monstr, netdev
In-Reply-To: <45cb2254ff23a4977c95b0f9459e39a6.squirrel@www.liukuma.net>
On Wed, Apr 20, 2011 at 12:02 AM, juice <juice@swagman.org> wrote:
>
> Hi!
>
> I can see you are probably going to run into CPU performance problems, but
> it depends a lot on the type of traffic you are going to send.
>
> My system requires quite fast processor, but even more important is to
> have a network interface card that really supports the full speed of
> gigabit ethernet line. The reason for that is that my test traffic
> includes streams of very small packets that cause a lot of overhead in
> processing.
>
> Most of my test traffic is UDP, but it does not really matter what the
> higher layers of the traffic are, this scheme operates on the ethernet
> layer and does not care about payload structure.
>
> I tried several NIC:s before i settled using Intel 82576 cards with the
> igb driver. If you have less capable interface card, your small packet
> performance is going to be a lot poorer.
>
> Using that card I can get to full speed GE line rate even with 64byte
> packets, but if you want to send larger packets, say close to 1500byte
> then almost any NIC will work OK for you.
>
> You can download the module code and the userland seeding application from
> my svn server at https://toosa.swagman.org/svn/streamgen
> The streamseed userland application requires libpcap-dev to build
> correctly but the streamgen module is self-sufficent.
>
> There is not a lot of documentation, and the module is still "work in
> progress" as I am going to fix it to work with more than one interface at
> the same time when I get to do it. Currently it can only use one interface
> on the sending host machine.
>
> - Juice -
>
does it use the same command/config file as pktgen?
or special command?
>
>> Hi Juice,
>>
>> juice wrote:
>>> Hi Michal.
>>>
>>> How fast do you need to send the data?
>>
>> It sounds weird but as fast as possible. There is no specific limit
>> because I
>> want to create demo and test it on various hw configuration which I can
>> easily
>> create on FPGA. For now the bottleneck is Microblaze cpu. It can run from
>> 50MHz
>> till 170-180MHz. We also support both endians and have two hw IP
>> cores(10/100/1000) which I can use.
>>
>>> I have an application where I send test stream out to GE line and can
>>> fill
>>> the total capacity of the ethernet regardless of the packet size.
>>
>> What cpu do you use?
>>
>>>
>>> The test stream I am sending is stored in kernel memory, and therefore
>>> is
>>> limited by the amount of free memory. 200M is no problem.
>>
>> Is it UDP or TCP?
>>
>>>
>>> The solution I am using is loosely based on the pktgen module, except
>>> that
>>> my module can load a wireshark capture from userland program and then
>>> send
>>> it from ethernet interface in wire speed.
>>
>> Sound good. Would it be possible to see it and test it?
>>
>> Thanks,
>> Michal
>>
>>
>>>
>>> - Juice -
>>>
>>>
>>>> Hi,
>>>> I would like to create demo for high speed data sending from custom IP
>>> through
>>>> the ethernet. I think the best description is that there are dmaable
>>>> memory
>>>> mapped registers or just memory which store data I want to send (for
>>> example 200MB).
>>>> Linux should handle all communication between target(probably server)
>>> and
>>>> host
>>>> (client) but data in the packets should go from that custom IP and
>>>> can't go
>>>> through the kernel because of performance issue.
>>>> Ethernet core have own DMA which I could use but the question is if
>>> there
>>>> is any
>>>> option how to convince the kernel that data will go directly from
>>>> memory
>>> mapped
>>>> registers and the kernel/driver/... just setup dma BD for headers and
>>> second for
>>>> data.
>>>> Do you have any experience with any solution with passing data
>>> completely
>>>> out of
>>>> kernel?
>>>> Thanks,
>>>> Michal
>>>> --
>>>> Michal Simek, Ing. (M.Eng)
>>>> w: www.monstr.eu p: +42-0-721842854
>>>> Maintainer of Linux kernel 2.6 Microblaze Linux -
>>>> http://www.monstr.eu/fdt/
>>>> Microblaze U-BOOT custodian
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the
>>> body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng)
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel 2.6 Microblaze Linux -
>> http://www.monstr.eu/fdt/
>> Microblaze U-BOOT custodian
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted
From: Alan Stern @ 2011-04-21 14:03 UTC (permalink / raw)
To: Paul Stewart
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, greg-U8xfFu+wG4EAvxtiuMwx3w
In-Reply-To: <20110420214452.C599321126-6A69KNNYBwgF248FYctl9mCaruZE5nAUZeezCHUQhQ4@public.gmane.org>
On Tue, 19 Apr 2011, Paul Stewart wrote:
> Set a flag if the interrupt URB completes with ENOENT as this
> occurs legitimately during system suspend. When the
> usbnet_resume is called, test this flag and try once to resubmit
> the interrupt URB.
I still don't think this is the best way to go.
> This version of the patch moves the urb submit directly into
> usbnet_resume. Is it okay to submit a GFP_KERNEL urb from
> usbnet_resume()?
Yes, it is.
> Signed-off-by: Paul Stewart <pstew-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
> drivers/net/usb/usbnet.c | 13 ++++++++++++-
> include/linux/usb/usbnet.h | 1 +
> 2 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 02d25c7..3651a48 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -482,6 +482,7 @@ static void intr_complete (struct urb *urb)
> case -ESHUTDOWN: /* hardware gone */
> if (netif_msg_ifdown (dev))
> devdbg (dev, "intr shutdown, code %d", status);
> + set_bit(EVENT_INTR_HALT, &dev->flags);
Is this new flag really needed?
> return;
>
> /* NOTE: not throttling like RX/TX, since this endpoint
> @@ -1294,9 +1295,19 @@ int usbnet_resume (struct usb_interface *intf)
> {
> struct usbnet *dev = usb_get_intfdata(intf);
>
> - if (!--dev->suspend_count)
> + if (!--dev->suspend_count) {
> tasklet_schedule (&dev->bh);
>
> + /* resubmit interrupt URB if it was halted by suspend */
> + if (dev->interrupt && netif_running(dev->net) &&
> + netif_device_present(dev->net) &&
> + test_bit(EVENT_INTR_HALT, &dev->flags)) {
Why do you need the test_bit()? If the other conditions are all true,
don't you want to resubmit the interrupt URB regardless?
> + clear_bit(EVENT_INTR_HALT, &dev->flags);
> + usb_submit_urb(dev->interrupt, GFP_KERNEL);
> + }
> + }
> +}
> +
> return 0;
> }
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH V3 0/8] macvtap/vhost TX zero copy support
From: Jon Mason @ 2011-04-21 14:29 UTC (permalink / raw)
To: Shirley Ma
Cc: David Miller, mst, Eric Dumazet, Avi Kivity, Arnd Bergmann,
netdev, kvm, linux-kernel
In-Reply-To: <1303328216.19336.18.camel@localhost.localdomain>
On Wed, Apr 20, 2011 at 3:36 PM, Shirley Ma <mashirle@us.ibm.com> wrote:
> This patchset add supports for TX zero-copy between guest and host
> kernel through vhost. It significantly reduces CPU utilization on the
> local host on which the guest is located (It reduced 30-50% CPU usage
> for vhost thread for single stream test). The patchset is based on
> previous submission and comments from the community regarding when/how
> to handle guest kernel buffers to be released. This is the simplest
> approach I can think of after comparing with several other solutions.
>
> This patchset includes:
>
> 1/8: Add a new sock zero-copy flag, SOCK_ZEROCOPY;
>
> 2/8: Add a new device flag, NETIF_F_ZEROCOPY for lower level device
> support zero-copy;
>
> 3/8: Add a new struct skb_ubuf_info in skb_share_info for userspace
> buffers release callback when lower device DMA has done for that skb;
>
> 4/8: Add vhost zero-copy callback in vhost when skb last refcnt is gone;
> add vhost_zerocopy_add_used_and_signal to notify guest to release TX skb
> buffers.
>
> 5/8: Add macvtap zero-copy in lower device when sending packet is
> greater than 128 bytes.
>
> 6/8: Add Chelsio 10Gb NIC to zero copy feature flag
>
> 7/8: Add Intel 10Gb NIC zero copy feature flag
>
> 8/8: Add Emulex 10Gb NIC zero copy feature flag
Why are only these 3 drivers getting support? As far as I can tell,
the only requirement is HIGHDMA. If this is the case, is there really
a need for an additional flag to support this? If you can key off of
HIGHDMA, all devices that support this would get the benefit.
> The patchset is built against most recent linux 2.6.git. It has passed
> netperf/netserver multiple streams stress test on above NICs.
>
> The single stream test results from 2.6.37 kernel on Chelsio:
>
> 64K message size: copy_from_user dropped from 40% to 5%; vhost thread
> cpu utilization dropped from 76% to 28%
>
> I am collecting more test results against 2.6.39-rc3 kernel and will
> provide the test matrix later.
>
> Thanks
> Shirley
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Hight speed data sending from custom IP out of kernel
From: zhou rui @ 2011-04-21 14:31 UTC (permalink / raw)
To: juice; +Cc: monstr, netdev
In-Reply-To: <45cb2254ff23a4977c95b0f9459e39a6.squirrel@www.liukuma.net>
On Wed, Apr 20, 2011 at 12:02 AM, juice <juice@swagman.org> wrote:
>
> Hi!
>
> I can see you are probably going to run into CPU performance problems, but
> it depends a lot on the type of traffic you are going to send.
>
> My system requires quite fast processor, but even more important is to
> have a network interface card that really supports the full speed of
> gigabit ethernet line. The reason for that is that my test traffic
> includes streams of very small packets that cause a lot of overhead in
> processing.
>
> Most of my test traffic is UDP, but it does not really matter what the
> higher layers of the traffic are, this scheme operates on the ethernet
> layer and does not care about payload structure.
>
> I tried several NIC:s before i settled using Intel 82576 cards with the
> igb driver. If you have less capable interface card, your small packet
> performance is going to be a lot poorer.
>
> Using that card I can get to full speed GE line rate even with 64byte
> packets, but if you want to send larger packets, say close to 1500byte
> then almost any NIC will work OK for you.
>
> You can download the module code and the userland seeding application from
> my svn server at https://toosa.swagman.org/svn/streamgen
> The streamseed userland application requires libpcap-dev to build
> correctly but the streamgen module is self-sufficent.
>
> There is not a lot of documentation, and the module is still "work in
> progress" as I am going to fix it to work with more than one interface at
> the same time when I get to do it. Currently it can only use one interface
> on the sending host machine.
>
> - Juice -
>
does it use the same command/config file as pktgen?
or special command?
rui
>
>> Hi Juice,
>>
>> juice wrote:
>>> Hi Michal.
>>>
>>> How fast do you need to send the data?
>>
>> It sounds weird but as fast as possible. There is no specific limit
>> because I
>> want to create demo and test it on various hw configuration which I can
>> easily
>> create on FPGA. For now the bottleneck is Microblaze cpu. It can run from
>> 50MHz
>> till 170-180MHz. We also support both endians and have two hw IP
>> cores(10/100/1000) which I can use.
>>
>>> I have an application where I send test stream out to GE line and can
>>> fill
>>> the total capacity of the ethernet regardless of the packet size.
>>
>> What cpu do you use?
>>
>>>
>>> The test stream I am sending is stored in kernel memory, and therefore
>>> is
>>> limited by the amount of free memory. 200M is no problem.
>>
>> Is it UDP or TCP?
>>
>>>
>>> The solution I am using is loosely based on the pktgen module, except
>>> that
>>> my module can load a wireshark capture from userland program and then
>>> send
>>> it from ethernet interface in wire speed.
>>
>> Sound good. Would it be possible to see it and test it?
>>
>> Thanks,
>> Michal
>>
>>
>>>
>>> - Juice -
>>>
>>>
>>>> Hi,
>>>> I would like to create demo for high speed data sending from custom IP
>>> through
>>>> the ethernet. I think the best description is that there are dmaable
>>>> memory
>>>> mapped registers or just memory which store data I want to send (for
>>> example 200MB).
>>>> Linux should handle all communication between target(probably server)
>>> and
>>>> host
>>>> (client) but data in the packets should go from that custom IP and
>>>> can't go
>>>> through the kernel because of performance issue.
>>>> Ethernet core have own DMA which I could use but the question is if
>>> there
>>>> is any
>>>> option how to convince the kernel that data will go directly from
>>>> memory
>>> mapped
>>>> registers and the kernel/driver/... just setup dma BD for headers and
>>> second for
>>>> data.
>>>> Do you have any experience with any solution with passing data
>>> completely
>>>> out of
>>>> kernel?
>>>> Thanks,
>>>> Michal
>>>> --
>>>> Michal Simek, Ing. (M.Eng)
>>>> w: www.monstr.eu p: +42-0-721842854
>>>> Maintainer of Linux kernel 2.6 Microblaze Linux -
>>>> http://www.monstr.eu/fdt/
>>>> Microblaze U-BOOT custodian
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the
>>> body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Michal Simek, Ing. (M.Eng)
>> w: www.monstr.eu p: +42-0-721842854
>> Maintainer of Linux kernel 2.6 Microblaze Linux -
>> http://www.monstr.eu/fdt/
>> Microblaze U-BOOT custodian
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* rtnetlink and many VFs
From: Ben Hutchings @ 2011-04-21 14:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, sf-linux-drivers
My colleagues have been working on SR-IOV support for sfc. The hardware
supports up to 127 VFs per port.
If we configure all 127 VFs through the net device, an RTM_GETLINK dump
will need to include messages describing them, with a total size of:
127 * (sizeof(struct ifla_vf_mac) + sizeof(struct ifla_vf_vlan) +
sizeof(struct ifla_vf_tx_rate) + protocol overhead)
> 7112
These messages are nested within the message describing the device as a
whole, so they cannot be split. The maximum size of an outgoing netlink
message, based on NLMSG_GOODSIZE, seems to be min(PAGE_SIZE, 8192). So
when PAGE_SIZE = 4096 it is simply impossible to dump information about
such a device!
I think it needs to be made possible to grow a netlink skb during
generation of the first message. Userspace may still be unable to
receive the large message but at least it has a chance.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCHv4] usbnet: Resubmit interrupt URB once if halted
From: Paul Stewart @ 2011-04-21 14:44 UTC (permalink / raw)
To: Alan Stern
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, greg-U8xfFu+wG4EAvxtiuMwx3w
In-Reply-To: <Pine.LNX.4.44L0.1104210937360.1939-100000-IYeN2dnnYyZXsRXLowluHWD2FQJk+8+b@public.gmane.org>
On Thu, Apr 21, 2011 at 6:43 AM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> On Wed, 20 Apr 2011, Paul Stewart wrote:
>
>> On Wed, Apr 20, 2011 at 2:08 PM, Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLrNAH6kLmebB@public.gmane.orgdu> wrote:
>> > On Tue, 19 Apr 2011, Paul Stewart wrote:
>> >
>> >> Set a flag if the interrupt URB completes with ENOENT as this
>> >> occurs legitimately during system suspend. �When the usbnet_bh
>> >> is called after resume, test this flag and try once to resubmit
>> >> the interrupt URB.
>> >
>> > No doubt there's a good reason for doing things this way, but it isn't
>> > clear. �Why wait until usbnet_bh() is called after resume? �Why not
>> > resubmit the interrupt URB _during_ usbnet_resume()?
>>
>> Actually, I was doing this in the bh because of feedback I had gained
>> early in this process about not doing submit_urb in the resume().
>
> Do you have a URL for that feedback? In general, there's no reason not
> to resubmit URBs during a resume callback; lots of drivers do it. But
> usbnet may have some special requirements of its own that I'm not aware
> of.
>
>> If
>> that issue doesn't exist, that makes my work a lot easier. In testing
>> I found that just setting this to happen in the bh might be problematic
>> due to firing too early, so this is good news.
>>
>> >�This would seem
>> > to be the logical approach, seeing as how usbnet_suspend() kills the
>> > interrupt URB.
>>
>> Aha! But you'll see from the current version of my patch that we don't
>> actually ever kill the interrupt URB. It gets killed all on its own (by the
>> hcd?) and handed back to us in intr_complete(). This last bit about the
>> complete function being called was lost on me for a while which is why
>> in a previous iteration of the patch I was trying to kill the urb in suspend().
>
> Why not kill the interrupt URB while suspending? It's the proper thing
> to do. Otherwise you run the risk that an event might happen at just
> the wrong time, causing the interrupt URB to complete normally, but
> _after_ the driver has finished suspending. There's a good chance the
> driver would not process the event correctly.
I don't mind killing the URB. I'd want to set the halt flag as well
(more on why have a flag in response to your other email). You're
right that there may be a race between an interrupt URB arriving and
the onset of suspend, but I really can't imagine why I can't solve
that by setting the flag if a submit_urb() fails in intr_complete().
>
> Alan Stern
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* Re: [PATCH v5] net: bnx2x: convert to hw_features
From: Eric Dumazet @ 2011-04-21 14:52 UTC (permalink / raw)
To: Michał Mirosław; +Cc: netdev, Vladislav Zolotarov, Eilon Greenstein
In-Reply-To: <20110412193823.0823213A65@rere.qmqm.pl>
Le mardi 12 avril 2011 à 21:38 +0200, Michał Mirosław a écrit :
> Since ndo_fix_features callback is postponing features change when
> bp->recovery_state != BNX2X_RECOVERY_DONE, netdev_update_features()
> has to be called again when this condition changes. Previously,
> ethtool_ops->set_flags callback returned -EBUSY in that case
> (it's not possible in the new model).
>
> Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
>
> v5: - don't delay set_features, as it's rtnl_locked - same as recovery process
> v4: - complete bp->rx_csum -> NETIF_F_RXCSUM conversion
> - add check for failed ndo_set_features in ndo_open callback
> v3: - include NETIF_F_LRO in hw_features
> - don't call netdev_update_features() if bnx2x_nic_load() failed
> v2: - comment in ndo_fix_features callback
> ---
Hi guys
I am not sure its related to these changes, but I now have in
net-next-2.6 :
[ 23.674263] ------------[ cut here ]------------
[ 23.674266] WARNING: at net/core/dev.c:1318 dev_disable_lro+0x83/0x90()
[ 23.674270] Hardware name: ProLiant BL460c G6
[ 23.674273] Modules linked in: tg3 libphy sg
[ 23.674280] Pid: 3070, comm: sysctl Tainted: G W 2.6.39-rc2-01242-g3ef22b9-dirty #669
[ 23.674282] Call Trace:
[ 23.674285] [<ffffffff813b94f3>] ? dev_disable_lro+0x83/0x90
[ 23.674291] [<ffffffff81042c9b>] warn_slowpath_common+0x8b/0xc0
[ 23.674298] [<ffffffff81042ce5>] warn_slowpath_null+0x15/0x20
[ 23.674304] [<ffffffff813b94f3>] dev_disable_lro+0x83/0x90
[ 23.674309] [<ffffffff81429789>] devinet_sysctl_forward+0x199/0x210
[ 23.674313] [<ffffffff814296e4>] ? devinet_sysctl_forward+0xf4/0x210
[ 23.674318] [<ffffffff8104e712>] ? capable+0x12/0x20
[ 23.674324] [<ffffffff81168f45>] proc_sys_call_handler+0xb5/0xd0
[ 23.674328] [<ffffffff81168f6f>] proc_sys_write+0xf/0x20
[ 23.674334] [<ffffffff81105f39>] vfs_write+0xc9/0x170
[ 23.674339] [<ffffffff81106550>] sys_write+0x50/0x90
[ 23.674345] [<ffffffff814b95a0>] sysenter_dispatch+0x7/0x33
[ 23.674350] ---[ end trace 051ec497c66b228e ]---
Thanks
^ 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